PPP modem differences

Colin Helliwell colin.helliwell at ln-systems.com
Thu Mar 23 17:12:52 UTC 2017


Curiouser and curiouser....  [I was so much surprised, that for the moment I quite forgot how to speak good English]

I thought I was maybe homing in on this problem. I started capturing the following investigations, ready to post this. Then I got to the end of writing up the info below and while double-checking the results found that, somewhere along the way, it had magically started working again with MM.
I wonder if there's some NV settings which had been lost and then found themselves restored by some act of my experiments. 
No, I'm not developing on a HAL9000 - though it's beginning to feel like it!

Understand if there's little enthusiasm for discussing it! :S   I just fear that whatever was screwed up might come back and bite me/us again in the future.

[Now to try adding NM back in too..]


===== Written up *before* the above: ======

I restored a rootfs from just last week, which I'm 99+% sure was working with this modem - at the time I was trying to get to the bottom of problems with *terminating* the ppp, not establishing it the first place (lack of 'detach' on pppd)

But this is also not working with MM. But in experimenting with it, I found that leaving out MM and using pppd directly *can* work.
Well, works every other time (2nd/4th/etc). But I think that *may* be an un-related init problem, since the driver powers down the modem when all file handles are closed - it times out in the chat/connect ("Connect script failed"), rather than getting as far as the pppd LCP negotiation.


(Semi-)Working:

root at wg2xx-tx6s:~# pppd nodetach dump call nomgr
pppd options in effect:
debug           # (from /etc/ppp/peers/nomgr)
nodetach                # (from command line)
holdoff 10              # (from /etc/ppp/peers/nomgr)
persist         # (from /etc/ppp/peers/nomgr)
maxfail 1               # (from /etc/ppp/peers/nomgr)
dump            # (from command line)
noauth          # (from /etc/ppp/peers/nomgr)
/dev/ttyMux0            # (from /etc/ppp/peers/nomgr)
921600          # (from /etc/ppp/peers/nomgr)
lock            # (from /etc/ppp/peers/nomgr)
connect /usr/sbin/chat -v -t15 -f /etc/ppp/chatscripts/mobile-modem.chat                # (from /etc/ppp/peers/nomgr)
crtscts         # (from /etc/ppp/peers/nomgr)
modem           # (from /etc/ppp/peers/nomgr)
passive         # (from /etc/ppp/peers/nomgr)
hide-password           # (from /etc/ppp/peers/nomgr)
novj            # (from /etc/ppp/peers/nomgr)
noipdefault             # (from /etc/ppp/peers/nomgr)
ipcp-restart 5          # (from /etc/ppp/peers/nomgr)
defaultroute            # (from /etc/ppp/peers/nomgr)
usepeerdns              # (from /etc/ppp/peers/nomgr)
chat:  Mar 23 14:00:02 CONNECT
Script /usr/sbin/chat -v -t15 -f /etc/ppp/chatscripts/mobile-modem.chat finished (pid 1061), status = 0x0
Serial connection established.
using channel 3
Using interface ppp0
Connect: ppp0 <--> /dev/ttyMux0
sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0xbce9f8b2> <pcomp> <accomp>]
rcvd [LCP ConfNak id=0x1 <asyncmap 0xa0000>]
sent [LCP ConfReq id=0x2 <asyncmap 0xa0000> <magic 0xbce9f8b2> <pcomp> <accomp>]
rcvd [LCP ConfAck id=0x2 <asyncmap 0xa0000> <magic 0xbce9f8b2> <pcomp> <accomp>]
rcvd [LCP ConfReq id=0x3 <asyncmap 0xa0000> <pcomp> <accomp> <magic 0xa1714186> <auth chap MD5>]
No auth is possible
sent [LCP ConfRej id=0x3 <auth chap MD5>]
rcvd [LCP ConfReq id=0x5 <asyncmap 0xa0000> <pcomp> <accomp> <magic 0xa1714186> <auth pap>]
No auth is possible
sent [LCP ConfRej id=0x5 <auth pap>]
rcvd [LCP ConfReq id=0x7 <asyncmap 0xa0000> <pcomp> <accomp> <magic 0xa1714186>]
sent [LCP ConfAck id=0x7 <asyncmap 0xa0000> <pcomp> <accomp> <magic 0xa1714186>]
kernel does not support PPP filtering
sent [CCP ConfReq id=0x1 <deflate 15> <deflate(old#) 15> <bsd v1 15>]
sent [IPCP ConfReq id=0x1 <addr 0.0.0.0> <ms-dns1 0.0.0.0> <ms-dns2 0.0.0.0>]
rcvd [LCP ProtRej id=0x8 80 fd 01 01 00 0f 1a 04]
Protocol-Reject for 'Compression Control Protocol' (0x80fd) received
rcvd [IPCP ConfReq id=0x1 <addr 192.168.254.254>]
sent [IPCP ConfAck id=0x1 <addr 192.168.254.254>]
rcvd [IPCP ConfNak id=0x1 <addr 10.8.49.163> <ms-dns1 10.206.128.1> <ms-dns2 10.206.128.1>]
sent [IPCP ConfReq id=0x2 <addr 10.8.49.163> <ms-dns1 10.206.128.1> <ms-dns2 10.206.128.1>]
rcvd [IPCP ConfAck id=0x2 <addr 10.8.49.163> <ms-dns1 10.206.128.1> <ms-dns2 10.206.128.1>]
not replacing default route to eth0 [192.168.10.254]
local  IP address 10.8.49.163
remote IP address 192.168.254.254
primary   DNS address 10.206.128.1
secondary DNS address 10.206.128.1
Script /etc/ppp/ip-up started (pid 1062)
Script /etc/ppp/ip-up finished (pid 1062), status = 0x0


root at wg2xx-tx6s:~# cat /etc/ppp/peers/nomgr
ttyMux0
# Note: physical baud rate is determined in LinMux driver (linmuxcfg -b)
115200
lock
crtscts
modem
passive
novj
defaultroute
noipdefault
usepeerdns
noauth
hide-password
persist
holdoff 10
maxfail 1
debug
ipcp-restart 5
connect "/usr/sbin/chat -v -t15 -f /etc/ppp/chatscripts/mobile-modem.chat"

root at wg2xx-tx6s:~# cat /etc/ppp/chatscripts/mobile-modem.chat
ABORT 'BUSY'
ABORT 'NO CARRIER'
ABORT 'VOICE'
ABORT 'NO DIALTONE'
ABORT 'NO DIAL TONE'
ABORT 'NO ANSWER'
ABORT 'DELAYED'
REPORT CONNECT
TIMEOUT 20
#'' 'ATQ0'
'' 'AT'
#'OK-AT-OK' 'ATZ'
TIMEOUT 3
'OK' @/etc/ppp/chatscripts/pin
'OK\d-AT-OK' 'ATI'
#'OK' 'ATZ'
#'OK' 'ATQ0 V1 E1 S0=0 &C1 &D2 +FCLASS=0'
'OK' @/etc/ppp/chatscripts/mode
'OK-AT-OK' @/etc/ppp/chatscripts/apn
'OK' 'ATDT*99***1#'
TIMEOUT 30
CONNECT ''

root at wg2xx-tx6s:~# cat /etc/ppp/chatscripts/pin
AT

root at wg2xx-tx6s:~# cat /etc/ppp/chatscripts/mode
AT

root at wg2xx-tx6s:~# cat /etc/ppp/chatscripts/apn
AT+CGDCONT=1,"IP","wap.vodafone.co.uk"

===========


> On 22 March 2017 at 15:59 Dan Williams <dcbw at redhat.com> wrote:
> 
> On Wed, 2017-03-22 at 14:41 +0000, Colin Helliwell wrote:
> 
> > > On 22 March 2017 at 13:50 Dan Williams <dcbw at redhat.com> wrote:
> > > 
> > > On Wed, 2017-03-22 at 13:23 +0000, colin.helliwell at ln-systems.com
> > > wrote:
> > > 
> > > > I know this might not be an issue with MM, but as there's also a
> > > > lot
> > > > of
> > > > modem-savvy people here.. :)
> > > > 
> > > > I've got the same system trying to make a ppp connection via MM.
> > > > I'm
> > > > using
> > > > the same SIM card, and running
> > > >  mmcli -m 0 --simple-connect="apn=mobile.o2.co.uk"
> > > >  pppd nodetach call provider
> > > 
> > > Quite puzzling; I haven't seen these kinds of requests originating
> > > from
> > > the modem before. But some thoughts:
> > > 
> > > 1) same modem hardware? If so, same firmware? If not, I wouldn't be
> > > surprised that different hardware is working differently, though I
> > > haven't seen these kind of challenges from the modem before.
> > 
> > Nope - both Cinterion, but different models.
> 
> That would do it.
> 
> > > 2) Modems do store some state in NVRAM. Sometimes that can include
> > > things like the default authentication mechanism (CHAP vs. PAP vs.
> > > none). Perhaps your second device has a different setting for that
> > > PDP
> > > context; what does AT+CGDCONT=? say between them?
> > 
> > I'd looked at those, and they seemed sane (as far as they go).
> > Working:
> > mmcli -m 0 --command="AT+CGDCONT?"
> > response: '+CGDCONT: 1,"IP","wap.vodafone.co.uk","0.0.0.0",0,0
> > +CGDCONT: 2,"IPV4V6","wap.vodafone.co.uk","",0,0'
> > [MM log showed cid 1 being used in the AT*99]
> > 
> > Non-working:
> > mmcli -m 0 --command="AT+CGDCONT?"
> > response: '+CGDCONT: 1,"IP","wap.vodafone.co.uk","0.0.0.0",0,0'
> 
> What do you get for AT^SGAUTH? for both devices?
> 
> Dan
> 
> > I'm not sure where/when the 0.0.0.0 got inserted in the Working one.
> > It *wasn't* there to start with on the non-working one, so when I saw
> > that diff I re-configured to add it. But not working with nor without
> > that field.
> > 
> > > I assume these are Cinterion devices? Might be able to use some
> > > Cinterion AT commands to figure out if there are settings
> > > differences.


More information about the ModemManager-devel mailing list