Re: pppd gets no IP during dial-in with Sierra MC7710 qmi

[Bjørn Mork <bjorn mork no>]

Andreas Schigold <andreas schigold blankom de> writes:

> Hello members of this mailing-list,
>  
> I have a strange problem with the Sierra Wireless MC7710 module. I use
> a Buildroot-Linux on an Atmel AT91SAM9G20 processor and on USB
> connected the MC7710. The Kernel-version is 3.6.8.
>  
> I added the device-ID of the MC7710 to the sierra.ko-driver and tried
> to connect to the internet with pppd 2.4.5 and 2.4.4. I tried also the
> qcserial.ko driver. I tried many different pppd-configs and 2 MC7710
> modules. I get always the same result:
>  
> Dial-in, CHAP-authentification and LCP handshake works but IPCP-Nak
> messages are always empty. After that I also cannot stop the
> communication. The disconnect-script has no effekt. The one and only
> way to make AT-commands useable at ttyUSB2 is to switch off the modem
> and switch it on again.
>  
> I tested with two SIM-cards, one Simyo-card (telephone-contract in the
> german e-plus phone-net) and one T-Mobile-card (Just-Internet-contract
> in the Deutsche Telekom phone-net). Both cards are working in my
> mobile phone but with both cards I have the same result in the above
> mentioned configuration.
>  
> What do I make wrong? Can the MC7710 connect via AT-interface?

Yes, it most certainly can.

> Do I need a different firmware?

I don't think so.  I have not tried that exact version, but both older
and newer versions work fine with PPP so I don't think it matters.

> How can I install a new firmware in Linux?

That's not straight forward.  You will currently have to install the
out-of-tree GobiNet and run the proprietary Linux SDK to do so, AFAIK.
No support here on that.  Sierra Wireless should be able to help yout
with it.

(the above is unnecessarily complicated - the upgrade process will only
use the GobiNet driver to send a couple of QMI commands before starting
the upgrade.  The upgrade itself uses a variant of the QDL protocol
known from older firmware-less Gobi devices.  But none of this is
documented anywhere public).

> Or does it working just with the QMI-WWAN driver via the /dev/cdc-wdm
> file? To make the libqmi useable makes a lot of work since I need some
> other libs as prerequisite for this. At this moment they are not
> included in the buildroot-project.

The MC7710 is fully usable with PPP so you don't need QMI if you can
live with the speed penalty.

This project may be interest if you still want to look at QMI on an
embedded system: http://nbd.name/gitweb.cgi?p=uqmi.git
  
> Here is some printout of the AT-communication
>  
> AT!UDINFO?
> VID: 0x1199
> PID: 0x68A2
> Interface: QMI

So it is definitely in QMI mode, which means that you should use the
qcserial driver, not the sierra driver.  Both will work, but the sierra
driver sends a setup command the firmware does not respond to in QMI
mode, causing a 5 second delay on initialisation of each serial port.

> Manufacturer: Sierra Wireless, Incorporated
> Product: MC7710
> OK
>  
> AT+CPINC?
> +CPINC: 3,3,10,10
> OK
>  
> AT+CPIN=0000 // pin is manipulated here ;-)
> OK
>  
> ATI
> Manufacturer: Sierra Wireless, Incorporated
> Model: MC7710
> Revision: SWI9200X_03.00.11.00AP R4152 CARMD-EN-10527 2011/12/20 14:52:19
> IMEI: 358178040223994
> IMEI SV: 8
> FSN: CCQ1512141610
> 3GPP Release 8
> +GCAP: +CGSM,+DS,+ES
> OK
>  
> AT!GSTATUS?
> !GSTATUS:
> Current Time:  205              Temperature: 26
> Bootup Time:   1                Mode:        ONLINE
> System mode:   WCDMA            PS state:    Attached

Looks OK. Attached.

> Mar  4 12:49:06 LANIOS kern.info kernel: sierra 1-1:1.0: Sierra USB modem converter detected
> Mar  4 12:49:11 headend kern.info kernel: usb 1-1: Sierra USB modem converter now attached to ttyUSB0

There you have the 5 second timeout.  Don't see it on the other ports,
which is strange, but still:  Use qcserial instead to avoid this.

Should however not affect the connection results in any way.


> Mar  4 12:49:11 headend kern.info kernel: sierra 1-1:1.2: Sierra USB modem converter detected
> Mar  4 12:49:11 LANIOS kern.info kernel: usb 1-1: Sierra USB modem converter now attached to ttyUSB1
> Mar  4 12:49:11 LANIOS kern.info kernel: sierra 1-1:1.3: Sierra USB modem converter detected
> Mar  4 12:49:11 headend kern.info kernel: usb 1-1: Sierra USB modem converter now attached to ttyUSB2
> Mar  4 12:49:11 LANIOS kern.info kernel: sierra 1-1:1.8: Sierra USB modem converter detected
> Mar  4 12:49:11 LANIOS kern.info kernel: usb 1-1: Sierra USB modem converter now attached to ttyUSB3

interface #8 is the QMI/wwan interface.  Doesn't matter that the serial
driver binds to it as long as you don't use it, but you may want to fix
this. 

> Mar  4 13:17:01 LANIOS daemon.debug pppd[736]: sent [IPCP ConfReq id=0x1 <addr 0.0.0.0> <ms-dns1 0.0.0.0> 
> <ms-dns2 0.0.0.0>]
> Mar  4 13:17:02 LANIOS daemon.debug pppd[736]: rcvd [IPCP ConfNak id=0x1]
> Mar  4 13:17:02 LANIOS daemon.debug pppd[736]: sent [IPCP ConfReq id=0x2 <addr 0.0.0.0> <ms-dns1 0.0.0.0> 
> <ms-dns2 0.0.0.0>]
> Mar  4 13:17:03 LANIOS daemon.debug pppd[736]: rcvd [IPCP ConfNak id=0x2]
> Mar  4 13:17:03 LANIOS daemon.debug pppd[736]: sent [IPCP ConfReq id=0x3 <addr 0.0.0.0> <ms-dns1 0.0.0.0> 
> <ms-dns2 0.0.0.0>]
> Mar  4 13:17:04 LANIOS daemon.debug pppd[736]: rcvd [IPCP ConfNak id=0x3]
> Mar  4 13:17:04 LANIOS daemon.debug pppd[736]: sent [IPCP ConfReq id=0x4 <addr 0.0.0.0> <ms-dns1 0.0.0.0> 
> <ms-dns2 0.0.0.0>]
> Mar  4 13:17:05 LANIOS daemon.debug pppd[736]: rcvd [IPCP ConfNak id=0x4]

I am not that steady in ppp debugging, so I can very well be wrong. But
this looks strange to me. Why does your end (pppd) continue sending the
same request after it is NAKed? I'd expect this to look something like

 sent [IPCP ConfReq id=0x1 <addr 0.0.0.0> <ms-dns1 0.0.0.0> <ms-dns2 0.0.0.0>]
 rcvd [IPCP ConfNak id=0x1]
 sent [IPCP ConfReq id=0x2]

etc.  The lack of IPCP ConfReq from the other end is also surprising, so
there may be other things wrong. FWIW, this is how a ppp session on the
MC7710 looks here, when I attempt to set the same options you use (as
you can see, I am not able to make it send the DNS options):

# pppd dump noccp novj noauth nodetach ms-dns 0.0.0.0 ms-dns 0.0.0.0 debug user linux online no /dev/ttyUSB2 
0.0.0.0:0.0.0.0
pppd options in effect:
debug           # (from command line)
nodetach                # (from command line)
dump            # (from command line)
noauth          # (from command line)
user linux online no            # (from command line)
/dev/ttyUSB2            # (from command line)
lock            # (from /etc/ppp/options)
crtscts         # (from /etc/ppp/options)
modem           # (from /etc/ppp/options)
asyncmap 0              # (from /etc/ppp/options)
lcp-echo-failure 4              # (from /etc/ppp/options)
lcp-echo-interval 30            # (from /etc/ppp/options)
hide-password           # (from /etc/ppp/options)
novj            # (from command line)
ms-dns xxx # [don't know how to print value]            # (from command line)
:               # (from command line)
noccp           # (from command line)
noipx           # (from /etc/ppp/options)
using channel 9
Using interface ppp0
Connect: ppp0 <--> /dev/ttyUSB2
sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0x44e440b7> <pcomp> <accomp>]
rcvd [LCP ConfReq id=0xf <asyncmap 0x0> <auth chap MD5> <magic 0xbb53d4d8> <pcomp> <accomp>]
sent [LCP ConfAck id=0xf <asyncmap 0x0> <auth chap MD5> <magic 0xbb53d4d8> <pcomp> <accomp>]
rcvd [LCP ConfAck id=0x1 <asyncmap 0x0> <magic 0x44e440b7> <pcomp> <accomp>]
sent [LCP EchoReq id=0x0 magic=0x44e440b7]
rcvd [LCP DiscReq id=0x10 magic=0xbb53d4d8]
rcvd [CHAP Challenge id=0x1 <20528d249ec50aba7e6734191e8e76bf>, name = "UMTS_CHAP_SRVR"]
sent [CHAP Response id=0x1 <5a5c0a66fb0e42eafa5be04458bac05c>, name = "linux online no"]
rcvd [LCP EchoRep id=0x0 magic=0xbb53d4d8 44 e4 40 b7]
rcvd [CHAP Success id=0x1 ""]
CHAP authentication succeeded
CHAP authentication succeeded
sent [IPCP ConfReq id=0x1 <addr 0.0.0.0>]
rcvd [IPCP ConfReq id=0xa]
sent [IPCP ConfNak id=0xa <addr 0.0.0.0>]
rcvd [IPCP ConfNak id=0x1 <addr 77.16.176.99>]
sent [IPCP ConfReq id=0x2 <addr 77.16.176.99>]
rcvd [IPCP ConfReq id=0xb]
sent [IPCP ConfAck id=0xb]
rcvd [IPCP ConfAck id=0x2 <addr 77.16.176.99>]
Could not determine remote IP address: defaulting to 10.64.64.64
local  IP address 77.16.176.99
remote IP address 10.64.64.64
Script /etc/ppp/ip-up started (pid 29557)
Script /etc/ppp/ip-up finished (pid 29557), status = 0x0


Don't know if this helped anything....


Bjørn