Skip to contentSkip to conversation

RFCOMM does not call tty_hangup() when DCD is de-asserted

PATCH In review Timo Teräs 3 participants 4 messages Apr 20, 2005 – Apr 21, 2005

Subsystems (2)
lore
Share & tools
lore
#0 lore raw

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(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)
+			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) |
maintainer
#1 lore raw

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 by uart_handle_dcd_change() defined in include/linux/serial_core.h and 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

#2 lore raw

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 =20

	if ((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

#3 lore raw

Re: [Bluez-devel] [PATCH] RFCOMM does not call tty_hangup() whenDCD is de-asserted

In reply to Marcel Holtmann

Hi 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 by uart_handle_dcd_change() defined in include/linux/serial_core.h and 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