The central component of good modem support on Linux is ModemManager. The components, such as NetworkManager, that make use of modems in Linux would typically use the convenient D-Bus interface ModemManager provides.
Nevertheless, there’s more to good modem support than just ModemManager. There’s little standardization in the protocols that modems use and multiple components need to coordinate to support a wide range of hardware with all of its idiosyncrasies.
There’s more to good modem support than just ModemManager.
This article will provide a short overview of the modern Linux modem support stack and some recent changes to it. If you own a modem, we may need your help to ensure it’s well supported. Read on to find out how can you help!
The ModemManager
ModemManager watches for new hardware as it’s discovered by the kernel, determines the protocol that the particular modem understands and exposes a nice and consistent API for NetworkManager to use.
ModemManager has seen a new major version 1.6 recently. We’ve shipped a development snapshot in Fedora 24. Fedora 25 is going to ship the real thing. Apart from the support for a pile of new modem models and various internal improvements it adds quite some new features: perhaps most prominently the ability to reset the modem after waking up from suspend and support for establishing voice calls with supported hardware.
ModemManager has seen a new major version 1.6 recently.
Since early 1980’s modems would be managed using the text-based AT command set. It was initially conceived for modems that were very unlike today’s high-speed wireless ones which preferably use binary protocols: MBIM or QMI. ModemManager uses the libmbim and libqmi libraries to support them. New versions of both of these libraries were released with ModemManager 1.6 as well.
Before ModemManager can use the device, the kernel driver needs to take care of the lower level communication with the device. To do so, the kernel drivers need to be aware of the model numbers of the devices it recognizes. That means information about the new modem models needs to be added to the driver otherwise the kernel won’t recognize the device and in turn ModemManager will not be able to use it.
Mode switching
More often than not, there’s one more step in between the modem being inserted and the driver being able to bind to it: mode switching. After being inserted, a typical USB modem would disguise as a CD-ROM drive preloaded with software to manage it in Windows. The first thing that software would do is to issue a command to switch the device from CD-ROM mode to a modem mode.
After inserted, a typical USB modem would disguise as a CD-ROM drive preloaded with software to manage the modem in Windows.
Needless to say, the Windows tool is not particularly useful elsewhere. In Linux we prefer the modems to just work when inserted, without installing any vendor-supplied tooling. To switch the device to modem mode we use a tool called usb_modeswitch. It comes with a large database of modems together with the right commands to do the switch. New modem models typically need an entry in this database.
After switching, the kernel would recognize the device in modem mode and bind the driver. ModemManager in turn picks the optimal command set to use with the modem and exposes a nice interface for the modem on the system bus.
Here’s a picture that illustrates how the pieces fit together:
Driver binding
Ideally, this would be the end of the story. Unfortunately, in past it was not uncommon for kernel driver not to recognize some modem models. usb_modeswitch worked around this by manually binding the driver it deemed appropriate if it didn’t see any driver to bind to the device in a timely manner.
Despite being a terrible hack this worked fine most of the time. However, sometimes usb_modeswitch’s guess was wrong and it would bind an incompatible driver to a device yielding unpredictable results. Recently, the usb_modeswitch developers decided to finally lay the hack to rest and completely rely on good kernel support.
This is where we need your help. It could be that there still are devices that rely on the hack and need to be added to a kernel driver. Adding the driver is as simple as making the driver recognize one more model number—it just requires someone who has the hardware to report and test it.
To check if your modem works with the up-to-date modem support stack, you can participate in the upcoming Fedora 25 Modem Test Day on August 25ᵗʰ (or any other day, really). You can test with Fedora nightly composes, or install the updated modem stack from ModemManager COPR.
You can test with Fedora nightly composes, or install the updated modem stack from COPR.
We’re interested in hearing how it works for you. Happy testing!
Lubo
Thanks to Hannes Frederic Sowa, Phil Sutter, Dan Williams and Francesco Giudici who proof-read the article and corrected many mistakes.
