https://bugzilla.kernel.org/show_bug.cgi?id=80301 --- Comment #2 from kcilorak@xxxxxxxxx --- (In reply to Peter Hurley from comment #1) > (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. > Sorry about that I should have probably used XX:XX:XX:XX:XX:XX > > 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. > This is correct. I had forgotten about hcidump and couldn't see what the device was doing within minicom. > Opening a tty device that is not connected is not a bug. > I agree that this is probably not a bug. However this is NEW behavior. on previous kernels when the device Disconnects the port also closes. Meaning you can no longer open /dev/rfcomm[X]. On, for example, kernel 3.8 when you do an rfcomm bind /dev/rfcomm[X] will still be present but you can't open it with minicom or any other program. Now for the first time that I have seen on 3.15 and newer you can open /dev/rfcomm[X] regardless of whether the device is connected or disconnected. If this is a planned change in the functionality of rfcomm then I will adapt my program to this new behavior. I'm just a bit concerned that if this change was accidental then it might change again at a later date. I couldn't find any documentation explaining that this was intentional. > > 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? > I did, yes. > > 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:~$ This behavior happened to me 2 or 3 times yesterday but I can't get it to do this any more so I would argue this isn't a problem anymore and was a result of very specific actions that I cannot reproduce. -- 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
