[Bluez-devel] [PATCH] RFCOMM does not call tty_hangup() when DCD is de-asserted

[Bluez-devel] [PATCH] RFCOMM does not call tty_hangup() when DCD is de-asserted

[Timo Teräs]

[-- Attachment #1: Type: text/plain, Size: 820 bytes --]

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

[-- Attachment #2: bluez-dcd-fix.diff --]
[-- Type: text/plain, Size: 586 bytes --]

===== net/bluetooth/rfcomm/tty.c 1.36 vs edited =====
--- 1.36/net/bluetooth/rfcomm/tty.c	2005-04-13 15:55:20 +03:00
+++ edited/net/bluetooth/rfcomm/tty.c	2005-04-20 14:13:45 +03:00
@@ -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) |

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

[Marcel Holtmann]

Hi Timo,

> 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.

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.
 
> +	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
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

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

[Timo Teräs]

Hi Marcel,

ext Marcel Holtmann wrote:
> from my part this patch looks fine, but I don't like the modem emulatio=
n
> 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.

>>+	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

Signed-off-by: Timo Ter=E4s <ext-timo.teras@nokia.com>

=3D=3D=3D=3D=3D net/bluetooth/rfcomm/tty.c 1.36 vs edited =3D=3D=3D=3D=3D
--- 1.36/net/bluetooth/rfcomm/tty.c     2005-04-13 15:55:20 +03:00
+++ edited/net/bluetooth/rfcomm/tty.c   2005-04-20 15:56:31 +03:00
@@ -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
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

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

[Victor Shcherbatyuk]

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" <marcel@holtmann.org>
To: <bluez-devel@lists.sourceforge.net>
Sent: Wednesday, April 20, 2005 14:39
Subject: Re: [Bluez-devel] [PATCH] RFCOMM does not call tty_hangup() whenDCD 
is de-asserted


> Hi Timo,
>
>> 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.
>
> 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.
>
>> + 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
> Bluez-devel@lists.sourceforge.net
> 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
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel