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.:
/org/freedesktop/ModemManager1/Modem/0
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.
EquipmentIdentifier
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|bind", GOTO="mm_naming_rules_end" DEVPATH=="/devices/pci0000:00/0000:00:1d.0/usb4/4-1/4-1.5/4-1.5.5",ENV{ID_MM_PHYSDEV_UID}="USB1" DEVPATH=="/devices/pci0000:00/0000:00:1d.0/usb4/4-1/4-1.5/4-1.5.2",ENV{ID_MM_PHYSDEV_UID}="USB2" DEVPATH=="/devices/pci0000:00/0000:00:1d.0/usb4/4-1/4-1.5/4-1.5.3",ENV{ID_MM_PHYSDEV_UID}="USB3" DEVPATH=="/devices/pci0000:00/0000:00:1d.0/usb4/4-1/4-1.5/4-1.5.4",ENV{ID_MM_PHYSDEV_UID}="USB4" LABEL="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.
Posted on October 6, 2016, in Development, FreeDesktop Planet, GNOME Planet, Planets and tagged gnome, gnu/linux, ModemManager, udev. Bookmark the permalink. 7 Comments.
Hi Aleksander,
i hope, i don t bother you with the following question, but i don t know where to ask elsewhere and you already answered the question on different platforms years ago, that the work to make gsm voicecalls availeable is in progress.
On your latest changelog i found this:
+ * Voice interface:
+ ** Multiple improvements and fixes in the voice call management logic
+ implemented with generic AT commands.
+ ** Added AudioPort and AudioFormat properties to the Call object.
+ ** Added new generic audio channel setup/cleanup handlers in the Call object.
My question is, do you know of any GUI (like modemmanager-gui) which is able to use this implementation? Or “point me in the right direction”?
I just want to phone home 😉
Nevertheless, thank you for your work.
Your best option is to play with
mmcli
in order to use all those actions.Hi,
Do you have a suggestion for a clean automated way to setup apn and enable the bearer when plugging the device? in gsm mode it’s easy with network manager because it has the connection.autoconnect parameter. but on wwan0 interface N-M does not know if the bearer is connected. I wish N-M would have such a nice way to invoke mmcli for wwan0.
my question I meant for a regular distro, not for openwrt
> Do you have a suggestion for a clean automated way to setup apn and enable the bearer when plugging the device? in gsm mode it’s easy with network manager because it has the connection.autoconnect parameter. but on wwan0 interface N-M does not know if the bearer is connected. I wish N-M would have such a nice way to invoke mmcli for wwan0.
I believe you’re confusing things. One thing is how NetworkManager allows managing the automatic connection of a modem; and another thing is how the modem is detected by NetworkManager.
The connection.autoconnect parameter is available for all modem types, it applies to both “gsm” (3GPP) and “cdma” (3GPP2) settings, so there is no issue there.
Most new modems are 3GPP (gsm/gprs/edge/umts/hspa/lte/5gnr), and so you must setup “gsm” settings in NetworkManager for those modems. Don’t be confused by the name, it’s “gsm” settings what you need to setup.
Then the last thing is how NetworkManager refers to the modem. You cannot reference to the modem via the “wwan0” interface, as that is a data port. NetworkManager needs to reference the modem with its control port (e.g. usually a ttyUSB or a cdc-wdm port). If you know the control port in advance, you may be able to create settings for a specific control port.
BUT the easiest way to handle this if you have one single modem in the system is to just create NetworkManager settings, with “gsm” specific settings, without specifying a specific interface port name anywhere: no cdc-wdm, no ttyUSB, no wwan. Once NetworkManager detects the modem, it will be able to assign those settings on the fly, as it will know they match.
ah, interesting. All this time I assumed the automatic way only works with tty type, and not also with cdc-ncm. I followed your advice and I see it magically connected, and is using the cdc ncm wwan interface, instead of old/slow ttyUSB interface with pppd!
that explains why I don’t see the wwan interface in ‘nmcli devices’ when I have NetworkManager-wwan package installed, correct?
(when the package is uninstalled, I can see wwp0s29u1u8i2 instead of ttyUSB0 in `nmcli device`; then I could do mmcli –simple-connect and nmcli connection add type generic to configure it)
Thank you for this post and you work on ModemManager. One thing worth updating.
ACTION!=”add|change|move” <- needed to add "bind" here as well.
Unfortunately it isn't well documented what ACTIONS kernel creates in what conditions, and recording the events boot-time isn't straightforward either.