At least under certain circumstances MC8705 devices do not work with Linux Kernel, ModemManager and NetworkManger. The root cause seems to be the following two kernel patches which are part of kernel 3.10 and later:
usbnet: allow status interrupt URB to always be active
and
sierra_net: keep status interrupt URB active
If the two patches are reverted the modem works. Of course, if the patches are not in the kernel the problem mentioned in the commit message of the patches pops up. Meaning the modem just crashes after a while…
If the patches are in the kernel the wwan interface does not get an IP address. The modem itself has a valid IP address.
Are there any recommendations?
Are you running a kernel with this commit (or a backport of it)?:
git.kernel.org/cgit/linux/kernel … 0d9aaa621f
It was supposed to fix the problems caused by status interrupt commits you point to.
We had a long discussion around this a year ago, ending up with that conclusion:
spinics.net/lists/linux-usb/msg97306.html
Thank you for this helpful response. The kernels I’m using are 3.14…3.14.19 which include the mentioned patch. On the basis of your response I double checked everything again. Here is a summary of my findings:
The main line kernel does not work. The show stopper is the patch “usbnet: allow status interrupt URB to always be active”. If this patch is reverted, the system gets an IP after boot.
Please find the boot log of the original kernel as an attachment. The device mobile0 ends up in a dead locked state.
There is also a successful boot log attached which results in IP connectivity for device mobile0. The only difference between the system which gets an IP address and the system which does not is that the latter does not have the “usbnet: allow status interrupt URB to always be active” applied.
Some notes about the system:
[] The modem is connected to an USB port where the supply voltage can be controlled by software. Hence the modem is hot plugged (initiated by software con2d during boot).[/]
[] ModemManager 1.4 [/]
[] NetworkManager 0.9.10[/]
[] Linux distribution is based on Yocto 1.6 [/]
works_3.14.19_reverted_usbnet.log (66.9 KB)
works_not_orig_3.14.19.log (108 KB)
OK, thanks for checking. Then I guess the problem must be something else.
Based on the logs, I am not sure the conclusion is correct. The patch revert seems to have caused a failure in the sierra_net module, resulting in much bigger differences between the two tests: The working case use PPP.
Just to make it clear: The changes we discuss affect only the sierra_net driver (i.e DirectIP). The sierra serial driver is not affected, and PPP should therefore work equally well both with and without the patch. So by testing without the sierra_net driver you have only shown that the problem is related to DirectIP, and not necessarily to the patch in question. Specifically we do not know whether DirectIP works at all with your configuration.
From your working log, we see that sierra_net fails to load due to missing symbols. This looks like the result of a partial revert where the symbols were removed from usbnet but are still referenced by sierra_net. And as you can see, NM/MM connects successfully using PPP over ttyUSB3:
Nov 10 08:50:24 nemp kernel: usbcore: registered new interface driver usbserial
Nov 10 08:50:24 nemp kernel: usbcore: registered new interface driver sierra
Nov 10 08:50:24 nemp kernel: sierra_net: Unknown symbol usbnet_status_start (err 0)
Nov 10 08:50:24 nemp kernel: usbserial: USB Serial support registered for Sierra USB modem
Nov 10 08:50:24 nemp kernel: sierra 2-2.1:1.0: Sierra USB modem converter detected
Nov 10 08:50:24 nemp kernel: sierra_net: Unknown symbol usbnet_status_stop (err 0)
Nov 10 08:50:24 nemp kernel: usb 2-2.1: Sierra USB modem converter now attached to ttyUSB0
Nov 10 08:50:24 nemp kernel: sierra 2-2.1:1.1: Sierra USB modem converter detected
Nov 10 08:50:24 nemp kernel: usb 2-2.1: Sierra USB modem converter now attached to ttyUSB1
Nov 10 08:50:24 nemp kernel: sierra 2-2.1:1.2: Sierra USB modem converter detected
Nov 10 08:50:24 nemp kernel: usb 2-2.1: Sierra USB modem converter now attached to ttyUSB2
Nov 10 08:50:24 nemp kernel: sierra 2-2.1:1.3: Sierra USB modem converter detected
Nov 10 08:50:24 nemp kernel: usb 2-2.1: Sierra USB modem converter now attached to ttyUSB3
Nov 10 08:50:24 nemp kernel: sierra 2-2.1:1.4: Sierra USB modem converter detected
Nov 10 08:50:24 nemp kernel: usb 2-2.1: Sierra USB modem converter now attached to ttyUSB4
..
Nov 10 08:50:42 nemp ModemManager[115]: <info> Creating modem with plugin 'Sierra' and '5' ports
..
Nov 10 08:50:57 nemp pppd[455]: Connect: ppp0 <--> /dev/ttyUSB3
..
Nov 10 08:50:59 nemp pppd[455]: local IP address 10.75.12.196In the non-working case, sierra_net loads successfully and MM finds 6 ports instead of 5. The 6th of course being the wwan0 netdev. It still uses ttyUSB3 as the management port to configure the modem and initiate the connection, but this fails with an “Cannot add new bearer: already reached maximum” error:
Nov 10 09:36:06 nemp kernel: usbcore: registered new interface driver usbserial
Nov 10 09:36:06 nemp kernel: usbcore: registered new interface driver sierra
Nov 10 09:36:06 nemp kernel: sierra_net 2-2.1:1.7 wwan0: register 'sierra_net' at usb-0000:00:0b.1-2.1, Sierra Wireless USB-to-WWAN Modem, 42:7f:70:02:01:07
Nov 10 09:36:06 nemp kernel: usbserial: USB Serial support registered for Sierra USB modem
Nov 10 09:36:06 nemp kernel: usbcore: registered new interface driver sierra_net
Nov 10 09:36:06 nemp kernel: sierra 2-2.1:1.0: Sierra USB modem converter detected
Nov 10 09:36:06 nemp kernel: usb 2-2.1: Sierra USB modem converter now attached to ttyUSB0
Nov 10 09:36:06 nemp kernel: sierra 2-2.1:1.1: Sierra USB modem converter detected
Nov 10 09:36:06 nemp kernel: usb 2-2.1: Sierra USB modem converter now attached to ttyUSB1
Nov 10 09:36:06 nemp kernel: sierra 2-2.1:1.2: Sierra USB modem converter detected
Nov 10 09:36:06 nemp kernel: usb 2-2.1: Sierra USB modem converter now attached to ttyUSB2
Nov 10 09:36:06 nemp kernel: sierra 2-2.1:1.3: Sierra USB modem converter detected
Nov 10 09:36:06 nemp kernel: usb 2-2.1: Sierra USB modem converter now attached to ttyUSB3
Nov 10 09:36:06 nemp kernel: sierra 2-2.1:1.4: Sierra USB modem converter detected
..
Nov 10 09:36:24 nemp ModemManager[115]: <info> Creating modem with plugin 'Sierra' and '6' ports
..
Nov 10 09:36:31 nemp NetworkManager[165]: <warn> (ttyUSB3) failed to connect modem: Cannot add new bearer: already reached maximum (1)I don’t think it’s obvious that this is related to a driver problem. It could be, but it could just as easily be a NM/MM configuration issue. Are you sure you have actually used sierra_net (DirectIP) successfully earlier? Could you try to do a complete revert of the patch in question, ensuring that the sierra_net loads successfully?
Oh, sorry for the stupid log file. Since the device was able to connect, I did not read the whole log file again. I just assumed that I posted I better formatted file of the flow I analyzed before… But I replaced only one of two kernel modules with the corresponding patched version.
The attached log file shows the right flow. It has been generated by a kernel without the mentioned patches (“usbnet: allow status interrupt URB to always be active” and "
sierra_net: keep status interrupt URB active"). Both modules load correctly and the device gets an IP address.
Honestly I am a little confused now. Without the sierra_net module the Linux kernel falls back to ppp mode, with sierra_net module it works in a completely different mode… I guess I should learn some basics about this part of the Linux network stack. Is there some documentation available?
Thank you very much for the fast response.
reverted_both.log (63.6 KB)
Thanks. So much easier comparing apples and apples 
I see now what I missed when reading the first set of logs: The connection attempt is repeated after the first failure, and the second attempt succeeds. So that failure was a red herring. This is the same both in the failing and the working case. The real difference between the failing and working case is later, when attempting to run the DHCP client. It’s not easy to see why this fails, but the “IPv6: ADDRCONF” messages from the kernel provides a hint consistent with your patching:
working:
Nov 10 13:41:48 nemp ModemManager[115]: <info> Simple connect state (8/8): All done
Nov 10 13:41:48 nemp kernel: IPv6: ADDRCONF(NETDEV_UP): wwan0: link is not ready
..
Nov 10 13:41:48 nemp kernel: IPv6: ADDRCONF(NETDEV_CHANGE): wwan0: link becomes ready
Nov 10 13:41:48 nemp NetworkManager[165]: <info> Activation (ttyUSB3) Stage 3 of 5 (IP Configure Start) scheduled.
Nov 10 13:41:48 nemp NetworkManager[165]: <info> Activation (ttyUSB3) Stage 3 of 5 (IP Configure Start) started...
Nov 10 13:41:48 nemp NetworkManager[165]: <info> (ttyUSB3): device state change: config -> ip-config (reason 'none') [50 70 0]
Nov 10 13:41:49 nemp NetworkManager[165]: <info> Activation (wwan0) Beginning DHCPv4 transaction (timeout in 45 seconds)
Nov 10 13:41:49 nemp NetworkManager[165]: <info> dhclient started with pid 458Failing:
Nov 10 09:36:35 nemp ModemManager[115]: <info> Simple connect state (8/8): All done
Nov 10 09:36:35 nemp kernel: IPv6: ADDRCONF(NETDEV_UP): wwan0: link is not ready
Nov 10 09:36:35 nemp NetworkManager[165]: <info> Activation (ttyUSB3) Stage 2 of 5 (Device Configure) scheduled...
Nov 10 09:36:35 nemp NetworkManager[165]: <info> Activation (ttyUSB3) Stage 2 of 5 (Device Configure) starting...
Nov 10 09:36:35 nemp NetworkManager[165]: <info> (ttyUSB3): device state change: prepare -> config (reason 'none') [40 50 0]
Nov 10 09:36:35 nemp NetworkManager[165]: <info> Activation (ttyUSB3) Stage 2 of 5 (Device Configure) successful.
Nov 10 09:36:35 nemp NetworkManager[165]: <info> Activation (ttyUSB3) Stage 2 of 5 (Device Configure) complete.
Nov 10 09:36:35 nemp Con2d[117]: Mobile0: DEBUG - Device None new State: (50) "The device is being configured." "OK"
Nov 10 09:36:36 nemp NetworkManager[165]: <info> Activation (ttyUSB3) Stage 3 of 5 (IP Configure Start) scheduled.
Nov 10 09:36:36 nemp NetworkManager[165]: <info> Activation (ttyUSB3) Stage 3 of 5 (IP Configure Start) started...
Nov 10 09:36:36 nemp NetworkManager[165]: <info> (ttyUSB3): device state change: config -> ip-config (reason 'none') [50 70 0]
Nov 10 09:36:36 nemp NetworkManager[165]: <info> Activation (wwan0) Beginning DHCPv4 transaction (timeout in 45 seconds)
Nov 10 09:36:36 nemp NetworkManager[165]: <info> dhclient started with pid 451Notice the lack of a “wwan0: link becomes ready” message there… This is exactly the kind of problem we would expect if we fail to read the status messages from the modem. So you are definitely on the track pointing to those patches.
This probably means that we fail to get the message that’s supposed to trigger a “link up” in the driver. I have no idea why… And I do not have any DirectIP modem available for testing myself at the moment. I suggest you take this bug to the netdev mailing list and/or Dan Williams (who wrote those patches).
This isn’t all that magic. The modem provides two different encapsulations on the USB link: PPP or ethernet (“DirectIP”). Both are supported both by the drivers (sierra and sierra_net respectively), and by ModemManager. And both modes are available simultaneously, using different USB interfaces/endpoints, although they share the same radio resource/link so only one mode can have an active connection. Which driver/encapsulation to use is up to the ModemManager modem plugin in the end. The “Sierra” plugin defaults to ethernet, and falls back to PPP if ethernet is unavailable.
PPP encapsulation has been used traditionally for 2G and 3G modems, even after they started doing packet mode access to the mobile networks. But with LTE, the PPP framing and escaping overhead became noticeable and most modem vendors started using packetized protocols for the USB link. DirectIP is Sierra’s variant. Other alternatives supported by some Sierra devices are QMI/RMNET (from Qualcomm) or CDC MBIM (from USB-IF).
Thank you very much for the answer. I think I learnt that DirectIP mode is broken and I have to use the old PPP mode. If sync messages are lost something seems to be really broken…