PPP modem differences

[Colin Helliwell]

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

Working:
'^SGAUTH: 1,0,""
^SGAUTH: 2,0,""
^SGAUTH: 3,0,""'

Non-working:
'^SGAUTH: 3'

Which are the factory defaults in both cases.
Changing on the non-working does affect auth negotiation:
0 (None):
{none}

1 (PAP):
rcvd [LCP ConfReq id=0x3 <asyncmap 0xa0000> <pcomp> <accomp> <magic 0xde9ad6b2> <auth pap>]
No auth is possible
sent [LCP ConfRej id=0x3 <auth pap>]

2 (CHAP):
rcvd [LCP ConfReq id=0x3 <asyncmap 0xa0000> <pcomp> <accomp> <magic 0xf59a42bd> <auth chap MD5>]
No auth is possible
sent [LCP ConfRej id=0x3 <auth chap MD5>]

3 (PAP & CHAP):
rcvd [LCP ConfReq id=0x3 <asyncmap 0xa0000> <pcomp> <accomp> <magic 0x6ed4f694> <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 0x6ed4f694> <auth pap>]
No auth is possible
sent [LCP ConfRej id=0x5 <auth pap>]

But even setting to 0 like the working one, still no connection:
Connect: ppp0 <--> /dev/ttyMux0
sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0xebf3f72d> <pcomp> <accomp>]
rcvd [LCP ConfNak id=0x1 <asyncmap 0xa0000>]
sent [LCP ConfReq id=0x2 <asyncmap 0xa0000> <magic 0xebf3f72d> <pcomp> <accomp>]
rcvd [LCP ConfAck id=0x2 <asyncmap 0xa0000> <magic 0xebf3f72d> <pcomp> <accomp>]
rcvd [LCP ConfReq id=0x3 <asyncmap 0xa0000> <pcomp> <accomp> <magic 0x1310cab1>]
sent [LCP ConfAck id=0x3 <asyncmap 0xa0000> <pcomp> <accomp> <magic 0x1310cab1>]
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=0x4 80 fd 01 01 00 0f 1a 04]
Protocol-Reject for 'Compression Control Protocol' (0x80fd) received
rcvd [LCP TermReq id=0x5]
LCP terminated by peer
sent [LCP TermAck id=0x5]
rcvd [LCP TermReq id=0x5]
sent [LCP TermAck id=0x5]
Connection terminated.
Modem hangup

Puzzled why the remote end requests a non-zero asyncmap, yet doesn't on the working one (same SIM/APN).