Detecting end of GSM datacall

Detecting end of GSM datacall

[Timo Teräs]

Hi,

I'm currently using PPP with GSM datacalls (PC connected using Bluetooth 
to mobile phone) and it works just fine. However, if I terminate the 
phone call from my mobile phone the loss of link is not detected.

I tracked down the reason: since the PPP link is between PC and remote 
computer, the mobile phone does not send any PPP packets that the link 
is dead. Instead it just sends '\r\nNO CARRIER\r\n'. And leaves the 
Bluetooth connection in AT command mode. Thus PPP stays happily up.

This AT info is received by the PPP async driver, but it stores it and 
does not process it since PPP_FLAG is never received in ppp_async_input().

Now I'm wondering what would be the proper way to fix this?

Thanks,
   Timo

RE: Detecting end of GSM datacall

[Steve Drew]

Hi Timo,

	I've had a similar issue with the Nokia mobiles I've been using, the workaround I've used is to put

lcp-echo-interval 4
lcp-echo-failure 2

into the my /etc/ppp/options file.

steve

-----Original Message-----
From: linux-ppp-owner@vger.kernel.org [mailto:linux-ppp-owner@vger.kernel.org] On Behalf Of Timo Teräs
Sent: 18 April 2005 10:58
To: linux-ppp@vger.kernel.org
Subject: Detecting end of GSM datacall

Hi,

I'm currently using PPP with GSM datacalls (PC connected using Bluetooth 
to mobile phone) and it works just fine. However, if I terminate the 
phone call from my mobile phone the loss of link is not detected.

I tracked down the reason: since the PPP link is between PC and remote 
computer, the mobile phone does not send any PPP packets that the link 
is dead. Instead it just sends '\r\nNO CARRIER\r\n'. And leaves the 
Bluetooth connection in AT command mode. Thus PPP stays happily up.

This AT info is received by the PPP async driver, but it stores it and 
does not process it since PPP_FLAG is never received in ppp_async_input().

Now I'm wondering what would be the proper way to fix this?

Thanks,
   Timo
-
To unsubscribe from this list: send the line "unsubscribe linux-ppp" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Detecting end of GSM datacall

[Timo Teräs]

ext Steve Drew wrote:
> 	I've had a similar issue with the Nokia mobiles I've been using, the workaround I've used is to put
> 
> lcp-echo-interval 4
> lcp-echo-failure 2
> 
> into the my /etc/ppp/options file.

Yes, this goes as a work around if the remote server supports lcp-echo. 
It also adds slight delay to the detection of the link going down. But 
I'd really like to have a proper fix for this. Any suggestions how to do 
that?

Is my only change to modify ppp_async_input() to detect this 'NO 
CARRIER' sequence and have it generate a LCP termination packet? Or is 
there some function that can be called to terminate the PPP link? Would 
this kind of solution be accepted the official kernel tree?

Cheers,
   Timo

Re: Detecting end of GSM datacall

[Jar]

> Yes, this goes as a work around if the remote server supports lcp-echo.

Are there servers which doesn't support lcp echo-request/echo-reply?

-- 
Best Regards, Jar

Re: Detecting end of GSM datacall

[Clifford Kite]

On Mon, 18 Apr 2005, Jar wrote:

|> Yes, this goes as a work around if the remote server supports lcp-echo.
|
|Are there servers which doesn't support lcp echo-request/echo-reply?

Depends on what "servers" means.  If it means "PPP implemetations"
then checkout the thread "PPPD via GPRS disconnection problem" in
comp.protocols.ppp.

---
Clifford Kite                                 http://ckite.no-ip.net

Re: Detecting end of GSM datacall

[Herbert Xu]

Clifford Kite <kite_linux-ppp@ev1.net> wrote:
> 
> Depends on what "servers" means.  If it means "PPP implemetations"
> then checkout the thread "PPPD via GPRS disconnection problem" in
> comp.protocols.ppp.

That can be worked around though, see

http://bugs.debian.org/301148
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
To unsubscribe from this list: send the line "unsubscribe linux-ppp" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Detecting end of GSM datacall

[Clifford Kite]

On Tue, 19 Apr 2005, Herbert Xu wrote:

|Clifford Kite <kite_linux-ppp@ev1.net> wrote:
|> 
|> Depends on what "servers" means.  If it means "PPP implemetations"
|> then checkout the thread "PPPD via GPRS disconnection problem" in
|> comp.protocols.ppp.
|
|That can be worked around though, see
|
|http://bugs.debian.org/301148

Sorry but I don't see any work-around there, only a suggestion to add
pppd code that would cause Code-Rejects to be counted as echo-replies.
It's Paul Mackerras' decision but, IMHO, there's a limit to "be liberal
in what you accept" (RFC 1122).

---
Clifford Kite                                 http://ckite.no-ip.net

Re: Detecting end of GSM datacall

[Paul Mackerras]

Timo Teräs writes:

> I'm currently using PPP with GSM datacalls (PC connected using Bluetooth 
> to mobile phone) and it works just fine. However, if I terminate the 
> phone call from my mobile phone the loss of link is not detected.
> 
> I tracked down the reason: since the PPP link is between PC and remote 
> computer, the mobile phone does not send any PPP packets that the link 
> is dead. Instead it just sends '\r\nNO CARRIER\r\n'. And leaves the 
> Bluetooth connection in AT command mode. Thus PPP stays happily up.

I don't think that just looking for that string would be the right
thing to do - what if someone sends you an email with that string in
it?  Every time you tried to download that email, ppp would
disconnect. :)

> This AT info is received by the PPP async driver, but it stores it and 
> does not process it since PPP_FLAG is never received in ppp_async_input().
> 
> Now I'm wondering what would be the proper way to fix this?

I suggest that you run pppd on a pty and have a little userspace
program to transfer characters between the pty and the real serial
port, much like the charshunt() function in pppd does.  That program
can do whatever hangup detection is appropriate.

Paul.

Re: Detecting end of GSM datacall

[Timo Teräs]

ext James Carlson wrote:
> Timo Teräs writes:
>>I tracked down the reason: since the PPP link is between PC and remote 
>>computer, the mobile phone does not send any PPP packets that the link 
>>is dead. Instead it just sends '\r\nNO CARRIER\r\n'. And leaves the 
>>Bluetooth connection in AT command mode. Thus PPP stays happily up.
> 
> Why doesn't it de-assert DCD (Data Carrier Detect) and thus cause pppd
> to receive SIGHUP as expected?
> 
> In my opinion, we shouldn't really go too far out of our way to make
> fatally compromised interfaces work "right."

Actually this is a very good question. I now finally solved this bug. It 
appears that BlueZ correctly translates/transports the carrier detect 
signal from my mobile. However it does not call tty_hangup() when the 
carrier detect is de-asserted. I managed to get this working perfectly 
well by adding one if () and tty_hangup() call to 
net/bluetooth/rfcomm/tty.c.

So this is actually a BlueZ emulation bug. I'll post bug report / simple 
patch to appropriate list asap.

Thanks,
   Timo