On a SIM7100A the PPPD connection fails (modem hangup) with nm-ppp-plugin, but a custom pppd script works
Aleksander Morgado
aleksander at aleksander.es
Tue May 11 18:35:55 UTC 2021
Hey!
>
> We have some strange behavior (on a SIM7100A) where NetworkManager (using the nm-ppp-plugin) needs to initiate a connection with Vodafone (private APN). The modem gets registered successfully on the network (roaming over the available T-Mobile or AT&T networks), but receives a modem hangup (the modem gives a "NO CARRIER" error) which leads to pppd disconnecting. However, when using a custom pppd script (and without using ModemManager & NetworkManager), we are able to setup a data connection.
This is a follow up of this email right?
https://lists.freedesktop.org/archives/modemmanager-devel/2021-April/008526.html
Just for context.
>
> * MM version is 1.14.10
> * NM version is 1.28.0
> * pppd version is 2.4.9
>
> When using NetworkManager the pppd options that seem to be used (from evaluating debug output of NetworkManager) are:
> ttyUSB2
> debug
> idle 0
> ipparam
> lcp-echo-failure 0
> lcp-echo-interval 0
> lock
> noauth
> nodefaultroute
> nodetach
> noipdefault
> noipv6
> usepeerdns
>
> and this results into the following pppd output:
> Serial connection established.
> using channel 23
> Using interface ppp0
> Connect: ppp0 <--> /dev/ttyUSB3
> sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0x8e804837> <pcomp> <accomp>]
> rcvd [LCP ConfReq id=0x3f <asyncmap 0x0> <auth chap MD5> <magic 0x88528a77> <pcomp> <accomp>]
> No auth is possible
> sent [LCP ConfRej id=0x3f <auth chap MD5>]
> rcvd [LCP ConfAck id=0x1 <asyncmap 0x0> <magic 0x8e804837> <pcomp> <accomp>]
> rcvd [LCP ConfReq id=0x40 <asyncmap 0x0> <magic 0x88528a77> <pcomp> <accomp>]
> sent [LCP ConfAck id=0x40 <asyncmap 0x0> <magic 0x88528a77> <pcomp> <accomp>]
> sent [IPCP ConfReq id=0x1 <addr 0.0.0.0> <ms-dns1 0.0.0.0> <ms-dns2 0.0.0.0>]
> sent [IPV6CP ConfReq id=0x1 <addr fe80::9095:1777:829f:47a0>]
> rcvd [LCP DiscReq id=0x41 magic=0x88528a77]
> Modem hangup
> Connection terminated.
>
> We do get good results when just running manual pppd script manually (no ModemManager and NetworkManager active), but with quite different options from the NetworkManager defaults. From the manual pppd script (a script taken from Quectel) the options are:
> debug
> defaultroute
> dump
> hide-password
> ipcp-accept-local
> ipcp-accept-remote
> ipcp-max-failure 30
> ipparam 3gppp
> lock
> modem
> noauth
> noccp
> nocrtscts
> nodetach
> noipdefault
> novj
> novjccomp
> remotename 3gppp
> usepeerdns
>
> And that gives a good result (shortened pppd output a bit):
> $ pppd debug call gprs
> pppd options in effect:
> debug debug
> nodetach
> dump
> noauth
> remotename 3gppp
> /dev/ttyUSB3
> 115200
> lock
> connect chat -s -v -f /data/ppp/chatscripts/quectel-chat-connect -T vf-viriciti
> disconnect chat -s -v -f /data/ppp/chatscripts/quectel-chat-disconnect
> nocrtscts
> modem
> hide-password
> novj
> novjccomp
> ipcp-accept-local
> ipcp-accept-remote
> ipparam 3gppp
> noipdefault
> ipcp-max-failure 30
> defaultroute
> usepeerdns
> noccp
> abort on (BUSY)
> abort on (NO CARRIER)
> abort on (NO DIALTONE)
> abort on (ERROR)
> abort on (NO ANSWER)
> timeout set to 30 seconds
> send (AT^M)
> expect (OK)
> AT^M^M
> OK
> -- got it
>
> send (ATE0^M)
> expect (OK)
> ^M
> ATE0^M^M
> OK
> -- got it
>
> send (ATI;+CSUB;+CSQ;+COPS?;+CGREG?;&D2^M)
> expect (OK)
> ^M
> ^M
> Manufacturer: SIMCOM INCORPORATED^M
> Model: SIMCOM_SIM7100A^M
> Revision: SIM7100A_V4.5^M
> IMEISV: 014339000429148/05^M
> +GCAP: +CGSM^M
> ^M
> +CSUB: B03V03^M
> +CSUB: MDM9x15_AP_S_V1.63_161010^M
> ^M
> +CSQ: 26,99^M
> ^M
> +COPS: 1,0,"T-Mobile DATA ONLY",7^M
> ^M
> +CGREG: 0,5^M
> ^M
> OK
> -- got it
>
> send (AT+COPS=1,2,310260^M)
> expect (OK)
> ^M
> ^M
> OK
> -- got it
>
> send (AT+CGDCONT=1,"IP","vf-viriciti",,0,0^M)
> expect (OK)
> ^M
> ^M
> OK
> -- got it
>
> send (ATDT*99***1#^M)
> expect (CONNECT)
> ^M
> ^M
> CONNECT
> -- got it
>
> Script chat -s -v -f /data/ppp/chatscripts/quectel-chat-connect -T vf-viriciti finished (pid 11933), status = 0x0
> Serial connection established.
> using channel 25
> Using interface ppp0
> Connect: ppp0 <--> /dev/ttyUSB3
> sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0xfb7fbc11> <pcomp> <accomp>]
> rcvd [LCP ConfReq id=0x0 <asyncmap 0x0> <auth chap MD5> <magic 0x8856fba8> <pcomp> <accomp>]
> No auth is possible
> sent [LCP ConfRej id=0x0 <auth chap MD5>]
> rcvd [LCP ConfAck id=0x1 <asyncmap 0x0> <magic 0xfb7fbc11> <pcomp> <accomp>]
> rcvd [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0x8856fba8> <pcomp> <accomp>]
> sent [LCP ConfAck id=0x1 <asyncmap 0x0> <magic 0x8856fba8> <pcomp> <accomp>]
> sent [IPCP ConfReq id=0x1 <addr 0.0.0.0> <ms-dns1 0.0.0.0> <ms-dns2 0.0.0.0>]
> sent [IPV6CP ConfReq id=0x1 <addr fe80::64c5:e93a:eca7:5409>]
> rcvd [LCP DiscReq id=0x2 magic=0x8856fba8]
> rcvd [IPCP ConfReq id=0x0]
> sent [IPCP ConfNak id=0x0 <addr 0.0.0.0>]
> rcvd [IPCP ConfNak id=0x1 <addr 10.141.107.204> <ms-dns1 10.1.2.199> <ms-dns2 10.1.2.200>]
> sent [IPCP ConfReq id=0x2 <addr 10.141.107.204> <ms-dns1 10.1.2.199> <ms-dns2 10.1.2.200>]
> rcvd [IPCP ConfReq id=0x1]
> sent [IPCP ConfAck id=0x1]
> rcvd [IPCP ConfAck id=0x2 <addr 10.141.107.204> <ms-dns1 10.1.2.199> <ms-dns2 10.1.2.200>]
> Could not determine remote IP address: defaulting to 10.64.64.64
> not replacing default route to eth0 [192.168.1.254]
> local IP address 10.141.107.204
> remote IP address 10.64.64.64
> primary DNS address 10.1.2.199
> secondary DNS address 10.1.2.200
> sent [IPV6CP ConfReq id=0x1 <addr fe80::64c5:e93a:eca7:5409>]
> sent [IPV6CP ConfReq id=0x1 <addr fe80::64c5:e93a:eca7:5409>]
>
>
> What we would like of course is for NetworkManager and the nm-ppp-plugin to basically also just get the connection up and running. At the moment we are clueless why the combination of ModemManager & NetworkManager is not able to obtain an active data sessions, but the manual pppd script is.
Have you tried to add to the NM plugin the options that are in the
manual pppd script?
>
> More (debug) info if attached in a pdf!
>
> I hope someone has any clue on the particular case, how to debug better, or can give an idea if this is a network operator sided issue.
>
I'm afraid I haven't seen an issue like this before myself.
--
Aleksander
https://aleksander.es
More information about the ModemManager-devel
mailing list