I’ve recently faced an issue with ModemManager running in an OpenWRT environment and this gave me the chance to take a deeper look at this kind of systems, something I never did in the past…
ModemManager and OpenWRT
One of the things to mention is that OpenWRT does not have udev, instead it relies on Procd (the OpenWrt process management daemon, basically a systemd replacement) executing hotplug scripts for signalling the ongoing events (e.g. a netdevice that changes its state).
By this simple description it is possible to understand how the results of the probing and modem detection part done by ModemManager could be somehow different in an OpenWRT system than the same happening in a standard Linux distribution supporting systemd and udev.
The OpenWRT ModemManager implementation is shipped with a series of hotplug scripts that are started when something happens at the kernel level, so that ModemManager can take care of the various events.
ModemManager is available in the OpenWRT/packages repository, together with the above mentioned hotplug scripts.
Everything is working pretty well and, based on my experience with Telit modems, it seems that ModemManager is becoming more and more used together with OpenWRT.
The multiplexing issue
So, an issue related to setting-up the data connection when using a Telit FN990 through rmnet was reported to me.
Looking at ModemManager log, it was clear that the issue was somehow related to the virtual qmap netdevice:
[modem0] state changed (disabled -> connecting)
[modem0/bearer0] net link qmimux0 created (mux id 1)
hotplug: add network interface qmimux0: event processed
hotplug: sysfspath is a virtual device (/sys/devices/virtual/net/qmimux0)
hotplug: add network interface qmimux1: event processed
hotplug: sysfspath is a virtual device (/sys/devices/virtual/net/qmimux1)
hotplug: add network interface qmimux2: event processed
hotplug: sysfspath is a virtual device (/sys/devices/virtual/net/qmimux2)
hotplug: add network interface qmimux3: event processed
hotplug: sysfspath is a virtual device (/sys/devices/virtual/net/qmimux3)
[modem0/bearer0] connection attempt #1 failed: Timed out waiting for link port 'net/qmimux0'However, I was not yet aware of how the kernel events were managed in this kind of systems, so I focused on the line that was not immediately clear for me:
hotplug: sysfspath is a virtual device (/sys/devices/virtual/net/qmimux0)Looking for that, I found file modemmanager.common and the function in which the suspicious line was printed: mm_report_event.
The comment related to virtual devices was not very clear to me, since I was just focusing on the virtual netdevices needed by ModemManager in this specific scenario. However, digging through the file history, I found commit e66fead “modemmanager: do not cache virtual device events”, explaining why virtual devices related events were excluded from the processing.
The next step for fixing the issue was to identify which netdevices required to be processed in the multiplexing scenario (i.e. the ones created with the two QMAP methods and the MBIM ones) and customizing the check done inside mm_report_event for virtual devices.
The final result is PR #23551 now merged in master.