Here’s a followup on my previous post Dell Wireless 5809e support in openSUSE 13.2.
First of all, one finds a lot of information on the Net about other Sierra Wireless modems such as MC7710, EM7345. It was not immediately obvious to me how such information relates to the EM7305 I have. Well, two things:
- MCxxxx and EMxxxx refer to different form factors: MCxxxx are PCI Express Mini cards whereas EMxxxx are PCI Express M.2 cards. MC87xx, MC90xx and EM88xx are HSPA+ (UMTS) modems, MC73xx/EM73xx are LTE modems (max. 150Mbps downstream) and MC74xx/EM74xx are LTE Advanced modems (max. 300Mbps downstream). All of these are part of Sierra Wireless’ AirPrime Essential modules family.
- The EM7345 is based on an Intel chip whereas the EM7305 is based on a Qualcomm chip, thus all information found eg. on zukota.com on flashing newer firmware, reviving bricked modems etc. does not apply.
Second, I was again investigating into using the modem’s QMI interface instead of the qcserial-based approach I described earlier. As I also described, loading qmi_wwan after switching the USB interface to configuration 1 didn’t seem to work for me. For this and other reasons I meanwhile upgraded to openSUSE Tumbleweed, but that alone didn’t solve the issue.
So I was trying out some other hints I found on the Web that promised to change the modem’s presentation to the host and as such its operation. If you load qcserial, feeding it with the USB vendor/product IDs as described, one of the /dev/ttyUSBx ports exposes an interface to feed the modem with AT commands. Make sure you kill ModemManager first to keep it from interfering when you run minicom.
This patchwork.ozlabs.org discussion suggested that setting a new USB product ID with AT!UDPID=... could force the modem into a QMI mode. This didn’t get me very far but I played around with AT!UDUSBCOMP=... which “sets USB interface configuration” — and almost bricked my modem, as I negligently chose one that disabled the presence of the AT interface. Luckily I could revive the modem by applying a firmware update unter Windows which seems to have reset the modem’s NVRAM configuration.
So better keep your hands off these commands, it is for a reason that they only work after a previous privileges enabling-command AT!ENTERCND="
Interestingly, after messing around with the modem’s USB interfaces and recovering it through the firmware update (I’m not really sure I had an older firmware version running before) and after reading the AT Command reference and especially the documentation on AT!UDUSBCOMP=..., I finally understood what’s going on.
Here’s an excerpt from the (safe) AT!UDUSBCOMP=? output:
[...] 5 - reserved NOT SUPPORTED 6 - DM NMEA AT QMI SUPPORTED 7 - DM NMEA AT RMNET1 RMNET2 RMNET3 SUPPORTED 8 - DM NMEA AT MBIM SUPPORTED 9 - MBIM SUPPORTED 10 - NMEA MBIM SUPPORTED 11 - DM MBIM SUPPORTED 12 - DM NMEA MBIM SUPPORTED 13 - Config1: comp6 Config2: comp8 NOT SUPPORTED 14 - Config1: comp6 Config2: comp9 SUPPORTED 15 - Config1: comp6 Config2: comp10 NOT SUPPORTED [...]
By default, the modem was in setting 14 as AT!UDUSBCOMP? tells us. Which means, it provides two alternate configuration modes which we can easily confirm by watching lsusb -v output and have already taken advantage of. By default, it also seems to be in Config2 which is described here as “comp9”. “comp” stands for composition and is a reference to mode 9: “MBIM”. Thus, the modem by default offers a MBIM interface, which was confirmed by my observations in my previous post.
As I learned yesterday night, MBIM is also supported natively on Windows 8 and later whereas Windows 7 does not have a standardized interface for mobile broadband — this explains the existence of QMI. Seeing that Windows 8 is Microsoft’s “current” operating system, it makes sense that the modem defaults to MBIM mode, not QMI.
What was not clear was what switching to configuration 1 via the udev rule really did — the lsusb output alone was not that helpful here.
Looking at the output above again shows: Config1 refers to “comp6” and mode 6 says: “DM NMEA AT QMI”. Well, we don’t know yet what DM is, but “NMEA” is used for reporting GPS information, “AT” is the very AT interface we’re just using and QMI is what we’re looking for. So that’s four interfaces which is exactly what we now see at the USB interface level. From usb-devices output:
T: Bus=02 Lev=01 Prnt=01 Port=07 Cnt=02 Dev#= 3 Spd=480 MxCh= 0 D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 2 P: Vendor=413c ProdID=81b1 Rev=00.06 S: Manufacturer=Sierra Wireless, Incorporated S: Product=Dell Wireless 5809e Gobi™ 4G LTE Mobile Broadband Card C: #Ifs= 4 Cfg#= 1 Atr=e0 MxPwr=500mA I: If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none) I: If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=(none) I: If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=(none) I: If#= 8 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
I already showed how we could get qcserial to cling on interfaces 2 and 3 and successively ModemManager to use the second ttyUSBx node to establish a connection. What was missing (and not working back then) was getting qmi_wwan to use interface 8, the QMI interface.
Without further ado, here’s my new /etc/udev/rules.d/99-dell5809e.rules file:
ACTION!="add|change", GOTO="mbim_to_qmi_rules_end"
SUBSYSTEM!="usb|drivers", GOTO="mbim_to_qmi_rules_end"
# load qmi_wwan module
SUBSYSTEM=="usb", \
ATTR{idVendor}=="413c", ATTR{idProduct}=="81b1", \
RUN+="/sbin/modprobe -b qmi_wwan"
# force Dell WWAN 5809e to configuration #1
SUBSYSTEM=="usb", \
ATTR{idVendor}=="413c", ATTR{idProduct}=="81b1", \
ATTR{bConfigurationValue}="1"
# add the new id in the qmi_wwan driver
SUBSYSTEM=="drivers", \
ENV{DEVPATH}=="/bus/usb/drivers/qmi_wwan", \
ATTR{new_id}="413c 81b1"
# load qcserial module
SUBSYSTEM=="usb", \
ATTR{idVendor}=="413c", ATTR{idProduct}=="81b1", \
RUN+="/sbin/modprobe -b qcserial"
# add the new id in the qcserial driver
SUBSYSTEM=="drivers", \
ENV{DEVPATH}=="/bus/usb-serial/drivers/qcserial", \
ATTR{new_id}="413c 81b1"
LABEL="mbim_to_qmi_rules_end"
With these udev rules, ModemManager establishes the connection via qmi_wwan and I can still get status information via ttyUSBx which is handled by qcserial. From usb-devices:
[...] C: #Ifs= 4 Cfg#= 1 Atr=e0 MxPwr=500mA I: If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none) I: If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=qcserial I: If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=qcserial I: If#= 8 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=qmi_wwan
Note that you do need a recent ModemManager version that includes Aleksander Morgado’s FCC Auth fix.
So to summarize this and my previous post:
- By default the modem is in MBIM mode, which is fine for Windows 8 but bad for Linux because current ModemManager versions a.) misdetect it as a Novatel modem, leading to the development of a new “Dell” plugin targeted for 1.6.0 and b.) even then, Aleksander yet has to find out how to send the “FCC Auth” sequence via MBIM as he already does in QMI mode since ModemManager 1.4.4 and libqmi 1.12.4.
- Switching it to configuration 1 will make the modem expose amongst others an serial interface for AT commands (that can be grabbed by qcserial) and a QMI interface (that can be grabbed by qmi_wwan).
- With the udev rules file above and a recent ModemManager version, you can now establish LTE connections without the bottleneck of the qcserial driver.
- There is thus no need to mess around with the privileged AT commands and you should take extremely care if doing so nevertheless.