https://bugzilla.kernel.org/show_bug.cgi?id=80301 --- Comment #1 from Peter Hurley <peter@xxxxxxxxxxxxxxxxxx> --- (In reply to kcilorak from comment #0) > This is kind of a strange one. > > When you create an RFCOMM connection with either > rfcomm bind rfcomm* 00:00:00:00:00:00 > or > rfcomm connect rfcomm* 00:00:00:00:00:00 At first I thought you were trying to connect to 00:00:00:00:00:00. I couldn't understand how you ever got that to work in any previous kernel. > The device works and the bluetooth hardware functions as expected, but when > you shut off the remote Bluetooth device or it gets out of range the RFCOMM > connection never closes. You can still open it with minicom or any other > application. There is nothing on the other end to talk to but you can open > it. The 'RFCOMM connection' does close, which you could verify with hcidump on either station. Opening a tty device that is not connected is not a bug. > In all previous kernels when the device shuts off or gets out of range the > port closes. With connect the port gets removed and with bind the connection > closes but the RFCOMM port still exists but you cannot access it. When you write 'port' here, you mean the /dev/rfcomm[X] device? > With this bug when using bind the port just starts working again when the > device becomes visible, so it seems like it never hangs up. Using connect > the RFCOMM connection eventually times out and the connect closes but the > RFCOMM doesn't leaving it corrupt and impossible to remove without a reboot. I could not reproduce this behavior. peter@thor:~$ sudo rfcomm connect rfcomm0 18:f4:6a:dd:5f:08 [sudo] password for peter: Connected /dev/rfcomm0 to 18:F4:6A:DD:5F:08 on channel 1 Press CTRL-C for hangup <walked remote device out of range> Disconnected peter@thor:~$ ls /dev/rfcomm* ls: cannot access /dev/rfcomm*: No such file or directory peter@thor:~$ -- You are receiving this mail because: You are the assignee for the bug. -- To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
