RFCOMM does not call tty_hangup() when DCD is de-asserted
Subsystems (2)
PATCH 1/1 RFCOMM does not call tty_hangup() when DCD is de-asserted
Hi all,
It seems that RFCOMM does not handle properly the de-assertation of CD signal. It should call tty_hangup() to work properly.
One side effect is that data calls that are hanged up from remote side are not detected as being hanged up.
I've made a very quick patch for this. In my case this patch enabled the detection carried detect signal de-assertation. But since I'm not an expert on RFCOMM stuff there might be some cases where tty_hangup() should not be called. In serial side the DCD change is handled by uart_handle_dcd_change() defined in include/linux/serial_core.h and it has some extra checks there as well.
So could some one wiser there check what actually has to be done for the hangup mechanism to work properly. Or if my patch looks good enough feel free to commit it.
Thanks,
Timo
===== net/bluetooth/rfcomm/tty.c 1.36 vs edited =====
net/bluetooth/rfcomm/tty.c +6 -0
@@ -531,6 +531,12 @@ static void rfcomm_dev_modem_status(struBT_DBG ("dlc %p dev %p v24_sig 0x%02x" , dlc, dev, v24_sig); +if ((dev->modem_status &TIOCM_CD ) && + !(v24_sig &RFCOMM_V24_DV )) { +if (dev->tty) +tty_hangup (dev->tty); + } + dev->modem_status = ((v24_sig &RFCOMM_V24_RTC ) ? (TIOCM_DSR |TIOCM_DTR ) :0 ) | ((v24_sig & RFCOMM_V24_RTR) ? (TIOCM_RTS | TIOCM_CTS) : 0) |
Marcel Holtmann
maintainerHi Timo,
Quoted 13 lines
It seems that RFCOMM does not handle properly the de-assertation of CD signal. It should call
tty_hangup()to work properly.One side effect is that data calls that are hanged up from remote side are not detected as being hanged up.
I've made a very quick patch for this. In my case this patch enabled the detection carried detect signal de-assertation. But since I'm not an expert on RFCOMM stuff there might be some cases where
tty_hangup()should not be called. In serial side the DCD change is handled byuart_handle_dcd_change()defined ininclude/linux/serial_core.hand it has some extra checks there as well.
Quoted 3 lines
So could some one wiser there check what actually has to be done for the hangup mechanism to work properly. Or if my patch looks good enough feel free to commit it.
from my part this patch looks fine, but I don't like the modem emulation part of RFCOMM in general. For me it is only a stream. Nothing less and nothing more. So if this patch is useful I am going to apply it.
net/bluetooth/rfcomm/tty.c static void rfcomm_dev_modem_status(stru · line 535
Quoted 2 lines
net/bluetooth/rfcomm/tty.c +2
-0+if ((dev->modem_status &TIOCM_CD ) && + !(v24_sig &RFCOMM_V24_DV )) {
You must comply with the coding style here. So change it into
if ((dev->modem_status & TIOCM_CD) && !(v24_sig & RFCOMM_V24_DV)) {And don't forget to add a Signed-off-by: line when you resend it.
Regards
Marcel
-------------------------------------------------------
This SF.Net email is sponsored by: New Crystal Reports XI. Version 11 adds new functionality designed to reduce time involved in creating, integrating, and deploying reporting solutions. Free runtime info, new features, or free trial, at: http://www.businessobjects.com/devxi/728
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Marcel,
Quoted 1 line · ext Marcel Holtmann
from my part this patch looks fine, but I don't like the modem emulatio=
n
Quoted 2 lines
part of RFCOMM in general. For me it is only a stream. Nothing less and nothing more. So if this patch is useful I am going to apply it.
PPP relies on this behaviour to detect when remote side has hang up the call. So PPP will be broken without this patch.
Quoted 6 lines
Review
Quoted 2 lines
(quoted diff) +2
-0+ if ((dev->modem_status & TIOCM_CD) && + !(v24_sig & RFCOMM_V24_DV)) {=20
You must comply with the coding style here. So change it into =20if ((dev->modem_status & TIOCM_CD) && !(v24_sig & RFCOMM_V24_DV)) {
Fixed. I also added check for CLOCAL being unset. If it is set modem cont= rol
lines should be ignored (also the uart code check for this).
Cheers,
Timo
=3D=3D=3D=3D=3D net/bluetooth/rfcomm/tty.c 1.36 vs edited =3D=3D=3D=3D=3D
net/bluetooth/rfcomm/tty.c 2005-04-20 15:56:31 +03:00 renamed from net/bluetooth/rfcomm/tty.c 2005-04-13 15:55:20 +03:00 +1 -0
@@ -531,6 +531,11 @@ static void rfcomm_dev_modem_status(stru BT_DBG("dlc %p dev %p v24_sig 0x%02x", dlc, dev, v24_sig); + if ((dev->modem_status & TIOCM_CD) && !(v24_sig & RFCOMM_V24_DV))=
{
+ if (dev->tty && !C_CLOCAL(dev->tty))
+ tty_hangup(dev->tty);
+ }
+
dev->modem_status =3D
((v24_sig & RFCOMM_V24_RTC) ? (TIOCM_DSR | TIOCM_DTR) : =
0) |
((v24_sig & RFCOMM_V24_RTR) ? (TIOCM_RTS | TIOCM_CTS) : =0) |
-------------------------------------------------------
This SF.Net email is sponsored by: New Crystal Reports XI. Version 11 adds new functionality designed to reduce time involved in creating, integrating, and deploying reporting solutions. Free runtime info, new features, or free trial, at: http://www.businessobjects.com/devxi/728
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Re: [Bluez-devel] [PATCH] RFCOMM does not call tty_hangup() whenDCD is de-asserted
In reply to Marcel HoltmannHi Marcel,
I've tried this patch on some of the phones, it is turned to be useful when using DUN profile of Windows CE phones, pppd used go to some weird state after an incoming call is picked up on that kind of phones, so it had to be killed and restarted to make it work again, with this patch it detects hang up and exits when the call is picked up, which makes the life simpler, no pppd - no connection - easy to detect...
Regards,
Victor.
P.S. for other phones I didn't see any strange behaviour yet...
----- Original Message ----- From: "Marcel Holtmann" <[email protected]>
To: <[email protected]>
Sent: Wednesday, April 20, 2005 14:39
Subject: Re: [Bluez-devel] [PATCH] RFCOMM does not call tty_hangup() whenDCD is de-asserted
Quoted 39 lines
Hi Timo,
Quoted 13 lines
It seems that RFCOMM does not handle properly the de-assertation of CD signal. It should call
tty_hangup()to work properly.One side effect is that data calls that are hanged up from remote side are not detected as being hanged up.
I've made a very quick patch for this. In my case this patch enabled the detection carried detect signal de-assertation. But since I'm not an expert on RFCOMM stuff there might be some cases where
tty_hangup()should not be called. In serial side the DCD change is handled byuart_handle_dcd_change()defined ininclude/linux/serial_core.hand it has some extra checks there as well.Quoted 3 lines
So could some one wiser there check what actually has to be done for the hangup mechanism to work properly. Or if my patch looks good enough feel free to commit it.
from my part this patch looks fine, but I don't like the modem emulation part of RFCOMM in general. For me it is only a stream. Nothing less and nothing more. So if this patch is useful I am going to apply it.
Quoted 2 lines
+ if ((
dev->modem_status&TIOCM_CD) &&
+ !(v24_sig &RFCOMM_V24_DV)) {You must comply with the coding style here. So change it into
if ((
dev->modem_status&TIOCM_CD) && !(v24_sig &RFCOMM_V24_DV)) {And don't forget to add a Signed-off-by: line when you resend it.
Regards
Marcel
Quoted 9 lines
-------------------------------------------------------
This SF.Net email is sponsored by: New Crystal Reports XI. Version 11 adds new functionality designed to reduce time involved in creating, integrating, and deploying reporting solutions. Free runtime info, new features, or free trial, at: http://www.businessobjects.com/devxi/728
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel