Blog Archives

Naming devices in ModemManager


No more “which is now the index of this modem…?”

DBus object path and index

When modems are detected by ModemManager and exposed in DBus, they are assigned an unique DBus object path, with a common prefix and a unique index number, e.g.:


This path is the one used by the mmcli command line tool to operate on a modem, so users can identify the device by the full path or just by the index, e.g. this two calls are totally equivalent:

$ mmcli -m /org/freedesktop/ModemManager1/Modem/0
$ mmcli -m 0

This logic looks good, except for the fact that there isn’t a fixed DBus object path for each modem detected: i.e. the index given to a device is the next one available, and if the device is power cycled or unplugged and replugged, a different index will be given to it.


Systems like NetworkManager handle this index change gracefully, just by assuming that the exposed device isn’t the same one as the one exposed earlier with a different index. If settings need to be applied to a specific device, they will be stored associated with the EquipmentIdentifier property of the modem, which is the same across reboots (i.e. the IMEI for GSM/UMTS/LTE devices).

User-provided names

The 1.8 stable release of ModemManager will come with support for user-provided names assigned to devices. A use case of this new feature is for example those custom systems where the user would like to assign a name to a device based on the USB port in which it is connected (e.g. assuming the USB hardware layout doesn’t change across reboots).

The user can specify the names (UID, unique IDs) just by tagging in udev the physical device that owns all ports of a modem with the new ID_MM_PHYSDEV_UID property. This tags need to be applied before the ID_MM_CANDIDATE properties, and therefore the rules file should be named before the 80-mm-candidate.rules one, for example like this:

$ cat /lib/udev/rules.d/78-mm-naming.rules

ACTION!="add|change|move", GOTO="mm_naming_rules_end"

The value of the new ID_MM_PHYSDEV_UID property will be used in the Device property exposed in the DBus object, and can also be used directly in mmcli calls instead of the path or index, e.g.:

$ mmcli -m USB4
 System | device: 'USB4'
        | drivers: 'qmi_wwan, qcserial'
        | plugin: 'Sierra'
        | primary port: 'cdc-wdm2'

Given that the same property value will always be set for the modem in a specific device path, this user provided names may unequivocally identify a specific modem even when the device is power-cycled, unplugged and replugged or even the whole system rebooted.

Binding the property to the device path is just an example of what could be done. There is no restriction on what the logic is to apply the ID_MM_PHYSDEV_UID property, so users may also choose other different approaches.

This support is already in ModemManager git master, and as already said, will be included in the stable 1.8 release, whenever that is.

TL;DR? ModemManager now supports assigning unique names to devices that stay even across full system reboots.

ModemManager, now with Iridium satellite network support

ModemManager and the Iridium satellite network

I recently sent a new ‘iridium’ plugin for review upstream, this time for Iridium modems. The plugin was developed using a Iridium 9522B Satellite Transceiver modem connected through RS232, properly handled by ModemManager’s plugin system thanks to the extended RS232 support available in git master. The ‘iridium’ plugin handles these modems as any other GSM modem, even if it has nothing to do with GSM technologies.

Iridium is a constellation of 66 active (plus spares) LEO satellites orbiting at an altitude of 781 km, which gives phone and network coverage to every point in Earth. It was initially thought to be a constellation of 77 satellites, therefore named ‘Iridium’ after the chemical element with atomic number 77. The name didn’t change to ‘Dysprosium‘ when it was redesigned to maintain only 66 active satellites, no wonder why.

Even if the Iridium modems expose a GSM-modem like AT command set, several special things needed to be considered. For example, IP address setup via PPP needed more than the 20s hardcoded in NetworkManager, due to the extreme latency of the satellite network. Therefore, NM was also updated to allow ModemManager plugins to specify a specific ‘IpTimeout’ value.

See my email to the NM mailing list for further information on how to use ModemManager with Iridium support.

Ammonit Measurement GmbH sponsoring some hardware for ModemManager development

In Lanedo we have worked with Ammonit Measurement GmbH to help them with the improvement of ModemManager to handle Wavecom, Cinterion and Iridium modems. The guys at Ammonit were kind enough to sponsor some modems, so that I can spend my free time in developing and improving ModemManager, as well as in testing the modems before stable releases (Dan will probably be happy for that):

  • Sierra Wireless Fastrack Xtend FXT009 (GPRS modem, USB, handled by the ‘wavecom’ plugin)
  • Cinterion TC63i (GPRS modem, RS232, handled by the ‘cinterion’ plugin)

So, thanks Ammonit!

Trisquel Taranis is here, including a MINI edition!

After a great job done during several months by Rubén and the rest of the Trisquel team, the long-waited Trisquel 4.0 Taranis” was published during the Software Freedom Day.

This new release of Trisquel is based on Ubuntu 10.04 “Lucid”, and provides a fully-free distribution of GNU/Linux, running the 100% free Linux-libre 2.6.32 kernel. This release comes in two different primary versions, the “Standard Edition” and the “Mini Edition”.

The “Standard Edition” is meant for standard desktop computers, and includes:

The “Mini Edition”, focused on computers with CPU/RAM limitations like Netbooks, includes:

I’ve been using Trisquel Taranis Standard Edition since some months ago, while it was not even in beta stage; but also wanted to check the look and feel and performance of the Mini version, so I decided to try it in a VM.

The boot menu when installing Trisquel Taranis is really appealing:

Boot menu in Trisquel Mini installation CD

Remember that you can try Trisquel GNU/Linux without installing it!

This is the initial look and feel of Trisquel Taranis Mini after installing it and logging in the user account. Note to Windows users, what’s the difference between a fresh Windows installation and a GNU/Linux installation? Just check the image…

The Trisquel Taranis Mini desktop

Answer: The “welcome” popup in GNU/Linux tells you about new software updates, it doesn’t tell you “Your computer is at risk!!!” because you didn’t install the antivirus or whatever. GNU/Linux doesn’t need an antivirus, and a fresh install is just SECURE, not like a Windows one.

The lightweight Mini edition will use only ~90MB of RAM when booted, which makes it perfect for netbooks and laptops without much memory:


So, if you want to give it a try, Download Trisquel Taranis! And if you like it, you can also Donate to the project, or buy some nice Trisquel Merchandise