Re: Sierra Wireless MC7750 / MM 0.7.990 / NM 0.9.8

[Aleksander Morgado <aleksander lanedo com>]

Hey Dana,

> Please forgive me if this list is not an appropriate venue for my question. I'm trying to get an integrated 
> Sierra Wireless MC7750 Modem (Verizon 4G LTE) up and running using the latest ModemManager (0.7/0.8), 
> libqmi, and NetworkManager 0.9.8.
>
> The modem works reliably on Windows.  I have also successfully gotten it to work (once!) on Linux, but the 
> configuration failed to survive a reboot.  It currently gives the following error when I try to connect 
> using NetworkManager:
>
> kma bree ~ $ !nmcli
> nmcli con up uuid 7a80b6d4-a52d-40c7-b279-7533422ff01e
> Error: Connection activation failed: The connection was not a 3GPP2 connection.
>
> This occurs very quickly, *as if* somehow Network Manager isn't even attempting to ask ModemManager to make 
> the connection (but I don't actually know this).  It certainly doesn't cause ModemManager to spit out its 
> own errors simultaneously.  (Both are logging debug level info).  I would expect to see complaints from 
> ModemManager as well, but all I get is the NetworkManager error.
>
> Any ideas how I managed to actually get a completely working configuration after installing updated package 
> builds --- but before rebooting --- and nothing but this 3GPP2 connection activation error since?  
> Unfortunately, one of the many things I tried doing after the reboot was deleting and re-creating the 4G 
> LTE connection in nm-connection-editor.


Please send full debug logs of both NM/MM, we really need to see the
sequence of events.

Also, please send the output of "mmcli -m 0".

Did you play with setting specific allowed modes? Did you actually try
to set "3G" only as allowed mode? There's a known issue in QMI-based
modems which prevents from setting 4G back as allowed mode in some cases.


> As an aside, how can I tell if we're trying to go through QMI or AT commands?  Is there a way to force 
> either one?  Is there a way to force a connection to a particular device in the system-connections 
> directory?  Is it possible some USB devices got shuffled around after rebooting?

You're being managed by QMI, as per the debug log chunks you attached.
There's currently no way to force one or the other; if the modem has a
QMI port, it will use QMI.


> I have also managed to get the the WWAN network up once or twice without Network Manager as follows:
>
> bree kma # more wwan_up.sh
> #!/bin/sh
> mmcli -m /org/freedesktop/ModemManager1/Modem/0 --set-allowed-modes=ANY --set-preferred-mode=3G

Just don't send the previous command. There's no way to tell a 4G
QMI-based modem that 3G is preferred over 4G. Mode preference is only
for 2G/3G.

> mmcli -m /org/freedesktop/ModemManager1/Modem/0 -e
> qmi-network /dev/cdc-wdm0 start

Uff.. no no; don't mix qmi-network and ModemManager :) There's only one
process allowed to actively use the QMI port; and if MM got it
qmi-network won't be able to work properly. Instead of the qmi-network
line, you can try the following:

 mmcli -m 0 --simple-connect="apn=yourapn"

> dhclient -d -4 wwan0
>
> bree kma # ./wwan_up.sh
> successfully set allowed modes in the modem
> successfully enabled the modem
> Starting network with 'qmicli -d /dev/cdc-wdm0 --wds-start-network=  --client-no-release-cid'...
> Saving state... (CID: 7)
> Saving state... (PDH: 42752512)
> Network started successfully
> Internet Systems Consortium DHCP Client 4.2.4
> Copyright 2004-2012 Internet Systems Consortium.
> All rights reserved.
> For info, please visit https://www.isc.org/software/dhcp/
>
> Listening on LPF/wwan0/7a:03:21:3e:3c:26
> Sending on   LPF/wwan0/7a:03:21:3e:3c:26
> Sending on   Socket/fallback
> DHCPREQUEST of 10.188.230.154 on wwan0 to 255.255.255.255 port 67
> DHCPREQUEST of 10.188.230.154 on wwan0 to 255.255.255.255 port 67
> DHCPNAK from 10.171.246.74
> DHCPDISCOVER on wwan0 to 255.255.255.255 port 67 interval 3
> DHCPREQUEST of 10.171.246.73 on wwan0 to 255.255.255.255 port 67
> DHCPOFFER of 10.171.246.73 from 10.171.246.74
> DHCPACK of 10.171.246.73 from 10.171.246.74
> Rather than invoking init scripts through /etc/init.d, use the service(8)
> utility, e.g. service smbd reload
>
> Since the script you are attempting to invoke has been converted to an
> Upstart job, you may also use the reload(8) utility, e.g. reload smbd
> bound to 10.171.246.73 -- renewal in 3169 seconds.
>
> ----
>
> However, this method is not reliable.

It is not reliable because the mix between qmi-network and ModemManager.
Just use MM/mmcli as explained before.


Cheers!

-- 
Aleksander