3

We have a Telit LE910 connected to a Gumstix Overo SBC. The Overo is running Yocto Linux (Kernel 3.21)

We have managed to get most things working but we now have an issue with the PPTP client.

When we try to initialise the PPPd we get the following output:

root@overo:~# pppd call telstra
AT
OK
AT+CGDCONT=1,"IP","telstra.internet"
OK
ATH
OK
ATE1
OK
AT+CSQ
+CSQ: 99,99

OK
ATD*99***1#
CONNECT
Script /usr/sbin/chat -v -f /etc/ppp/chat finished (pid 3768), status = 0x0
Serial connection established.
using channel 102
Using interface ppp0
Connect: ppp0 <--> /dev/ttyUSB2
sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0x7be0adcd> <pcomp> <accomp>]
rcvd [LCP ConfReq id=0xab <asyncmap 0x0> <auth chap MD5> <magic 0x909a1588> <pcomp> <accomp>]
No auth is possible
sent [LCP ConfRej id=0xab <auth chap MD5>]
rcvd [LCP ConfAck id=0x1 <asyncmap 0x0> <magic 0x7be0adcd> <pcomp> <accomp>]
rcvd [LCP ConfReq id=0xac <asyncmap 0x0> <magic 0x909a1588> <pcomp> <accomp>]
sent [LCP ConfAck id=0xac <asyncmap 0x0> <magic 0x909a1588> <pcomp> <accomp>]
sent [CCP ConfReq id=0x1 <deflate 15> <deflate(old#) 15>]
sent [IPCP ConfReq id=0x1 <compress VJ 0f 01> <addr 0.0.0.0>]
rcvd [LCP DiscReq id=0xad magic=0x909a1588]
rcvd [LCP ProtRej id=0xae 80 fd 01 01 00 0c 1a 04 78 00 18 04 78 00]
Protocol-Reject for 'Compression Control Protocol' (0x80fd) received
rcvd [IPCP ConfNak id=0x1 <ms-dns1 10.11.12.13> <ms-dns2 10.11.12.14> <ms-wins 10.11.12.13> <ms-wins 10.11.12.14>]
sent [IPCP ConfReq id=0x2 <compress VJ 0f 01> <addr 0.0.0.0> <ms-dns1 10.11.12.13> <ms-dns2 10.11.12.14> <ms-wins 10.11.12.13> <ms-wins 10.11.12.14>]
rcvd [IPCP ConfNak id=0x2 <ms-dns1 10.11.12.13> <ms-dns2 10.11.12.14> <ms-wins 10.11.12.13> <ms-wins 10.11.12.14>]
sent [IPCP ConfReq id=0x3 <compress VJ 0f 01> <addr 0.0.0.0> <ms-dns1 10.11.12.13> <ms-dns2 10.11.12.14> <ms-wins 10.11.12.13> <ms-wins 10.11.12.14>]
rcvd [IPCP ConfNak id=0x3 <ms-dns1 10.11.12.13> <ms-dns2 10.11.12.14> <ms-wins 10.11.12.13> <ms-wins 10.11.12.14>]
sent [IPCP ConfReq id=0x4 <compress VJ 0f 01> <addr 0.0.0.0> <ms-dns1 10.11.12.13> <ms-dns2 10.11.12.14> <ms-wins 10.11.12.13> <ms-wins 10.11.12.14>]
rcvd [IPCP ConfNak id=0x4 <ms-dns1 10.11.12.13> <ms-dns2 10.11.12.14> <ms-wins 10.11.12.13> <ms-wins 10.11.12.14>]
sent [IPCP ConfReq id=0x5 <compress VJ 0f 01> <addr 0.0.0.0> <ms-dns1 10.11.12.13> <ms-dns2 10.11.12.14> <ms-wins 10.11.12.13> <ms-wins 10.11.12.14>]
rcvd [IPCP ConfNak id=0x5 <ms-dns1 10.11.12.13> <ms-dns2 10.11.12.14> <ms-wins 10.11.12.13> <ms-wins 10.11.12.14>]
sent [IPCP ConfReq id=0x6 <compress VJ 0f 01> <addr 0.0.0.0> <ms-dns1 10.11.12.13> <ms-dns2 10.11.12.14> <ms-wins 10.11.12.13> <ms-wins 10.11.12.14>]

We did have this running on a development board, but despite using the same configuration, we haven't been able to get it working.

Is there a configuration issue or is there something more fundamental going on?

tl8
  • 141
  • 5
  • In the spirit of http://www.xkcd.com/979/, this is the same problem on https://forums.whirlpool.net.au/forum-replies.cfm?t=2575530 – tl8 Oct 19 '16 at 23:29

1 Answers1

1

After a lot of work, we have a working config and CHAT script.

I think the root cause is the lack of reception caused by a dodgy fly lead.

AT+CSQ

Will return the reception and the confidence figure (Lower is better for both). In the original log, this was 99,99. With a different fly lead the following is returned.

+CSQ: 15,99

The final chat script that was used is:

TIMEOUT 5
ECHO ON
ABORT '\nBUSY\r'
ABORT '\nERROR\r'
ABORT '\nNO ANSWER\r'
ABORT '\nNO CARRIER\r'
ABORT '\nNO DIALTONE\r'
ABORT '\nRINGING\r\n\r\nRINGING\r'
'' 'ATZ'
'' \rAT
TIMEOUT 30
OK 'AT+CSQ'
OK 'AT#SIMDET=1'
OK 'AT+CGDCONT = 1,"IP","telstra.internet"'
OK 'AT+CGDCONT?'
\r \d\c
'OK' 'ATD*99#'
\r \d\c
\r \d\c
'CONNECT' ''

The \r \d\c are a 1 second pause. As this is at boot and power up, being a bit slower is alright in this application.

This probably can be optimised.

The Peers script we are using is:

# initialization string.
connect "/usr/sbin/chat -v -f /etc/ppp/chat"
# Serial device to which the modem is connected.
/dev/ttyUSB2
# Speed of the serial line.
115200
# Assumes that your IP address is allocated dynamically by the ISP.
noipdefault
# Try to get the name server addresses from the ISP.
usepeerdns
#Use this  connection as the default route.
defaultroute
replacedefaultroute
# Makes pppd "dial again" when the connection is lost.
persist
# Do not ask the remote to authenticate.
noauth
# For testing purposes
debug
nodetach

This does work now so should be usable into the future.

tl8
  • 141
  • 5
  • I had problems resulting in *pppd* stating "Could not determine local IP address". After a lot of trial&error, adding additional 2 wait cycles after `AT+CGDCONT=...` to the ones listed above, plus adding the missing `replacedefaultroute` to the options did the trick for me. Awesome work, @tl8! – Murphy May 24 '18 at 15:58
  • And damn you, Telit, for wasting my time and nerves with brittle firmware. The original scripts *without* any wait cycles have worked for a HE910; and this wasn't the first impenetrable problem I had to work around. – Murphy May 24 '18 at 19:28