Detection failure with 1.20.4

Aleksander Morgado aleksandermj at
Tue Feb 7 11:18:57 UTC 2023


> Attached is a log of a modem detection failure I have on my system.  This
> platform is pretty similar to my legacy platform, but there are some differences:
> * Now running 5.10 series kernels on both.
> * The board has WiFi, which means a lot more of the PCI subsystem gets exposed
> in user space, which may be relevant for udev etc.
> * There's additional LAN ports and a WAN port - again, not directly relevant to
> modem detection, but might have some effects with udev too.
> * Subtle differences in USB hardware setup. There's a "USB passthrough" mode on
> this board, and sometimes this seems to misbehave. In one instance I saw the
> modem reported twice in lsusb, although this seems to have been a one-off.
> In this log, I've disabled PPP, and out of desperation, DHCP too, to limit
> the churn.  This problem appears 100% of the time at start up, and is only
> resolved by a restart of ModemManager, or a cycling of the USB interfaces
> (which the top-level monitoring script will eventually do, but takes some
> minutes in practice).
> The misdetection can happen on the legacy platform, but having disabled PPP
> and extra plugins it seems to be pretty rare.
> Let me know if there's extra debug I can provide.

The misdetection will happen regardless of whether you disable PPP or
other plugins, because it depends exclusively on how quick the ports
of a device are exposed by the kernel.
In your case (timing more or less):
 * 1675449157.916842: ttyUSB0 detected
 * 1675449158.692125: ttyUSB1 detected
 * 1675449159.415647: ttyUSB2 detected
 * 1675449160.178757: ttyUSB3 detected
 * 1675449163.204415: ModemManager decides no more ports are expected,
because the "extra probing time" has elapsed.

The "extra probing time" is the amount of time ModemManager waits for
a port to be notified since the last port notification on the same
device. For openwrt this is 3 seconds (1.5s when using udev), see

* 1675449163.515492: wwan0 detected
* 1675449163.604525: cdc-wdm0 detected

So in your case, it looks like we needed around 300ms more as "extra
probing time".

This issue is very very very dependent on the setup, and increasing
this timeout value unconditionally for everyone will make device
detection slower in cases where it wouldn't be needed. We should
definitely make this value configurable, e.g. via a udev tag, so that
users can adjust it if using slow systems.

Another way to approach this issue would be by forcing a full device
reprobe if we end up finding new ports added after we decided there
may not be more notified, as in your case. I believe I already tried
to do something like that months ago when we first discussed your
issues, and I drafted a patch, but which is totally untested and may
actually not work at all, here:
Would be good to revisit that approach maybe, as it would be
independent of the timing.


More information about the ModemManager-devel mailing list