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
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: [email protected] [mailto:[email protected]] On Behalf Of Timo Teräs
Sent: 18 April 2005 10:58
To: [email protected]
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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 6 lines · ext Steve Drew
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 2into the my
/etc/ppp/optionsfile.
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
Quoted 2 lines
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?
Signature · 1 line
Best Regards, Jar
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
�
On Tue, 19 Apr 2005, Herbert Xu wrote:
|Clifford Kite <[email protected]> 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
Quoted 8 lines · Timo Teräs
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. :)
Quoted 4 lines
This AT info is received by the PPP async driver, but it stores it and does not process it since
PPP_FLAGis never received inppp_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.
Quoted 11 lines · ext James Carlson
Quoted 4 lines · Timo Teräs
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