https://bugzilla.kernel.org/show_bug.cgi?id=80301 --- Comment #3 from Peter Hurley <peter@xxxxxxxxxxxxxxxxxx> --- (In reply to kcilorak from comment #2) > (In reply to Peter Hurley from comment #1) > > 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. Yeah, this was an intentional bug-fix to the behavior of open(O_NONBLOCK) on an rfcomm tty. open(fd, O_NONBLOCK) is specified (in SUS v3 & v4) to return without waiting for the device to be ready or available; the rfcomm driver was always waiting for connect regardless of the O_NONBLOCK setting. minicom uses open(O_NONBLOCK). Blocking open (ie., open() without O_NONBLOCK flag) behaves as before. > > > 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. If the rfcommX device is bound but never opened, then it can be explicitly released with: peter@thor:~$ sudo rfcomm release rfcomm0 Please feel free to add new information or steps to reproduce if it happens again. The automagic reference counting is very tricky and could easily still have a lurking bug. -- 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
