OpenWrt: unexpected disconnect requiring manual restart of ModemManager

Aleksander Morgado aleksander at aleksander.es
Sun Apr 26 09:51:07 UTC 2020


Hey!

>
> I assume the "(tty/ttyUSB6) at port timed out 10 consecutive times" is a
> real error, for unknown reasons. What's worrying me is how it is
> handled.  I do not expect the modem to disconnect and disappear from
> ModemManager due to an error like this, which seems to be related to the
> optional at port only. Giving up seems excessive. Restart is fine as a
> last resort.  Stop is not.
>

The AT port is optional in a QMI/MBIM based modem only in the sense
that it is not required for a data connection. Unfortunately, the AT
port in a QMI/MBIM modem is *not* optional if you require some
features that are only available via AT ports, e.g. thinking on the
most critical one being Voice support. In your setup, you don't want
to handle incoming calls, but there are other setups (e.g. the
Librem5) where losing the AT port would mean a very very critical
thing.

The fact that MM ends up removing the modem and gives up is not ideal,
I agree with that.

For cases where the AT port is the control port, removing the modem
from MM would trigger "upper layers" (e.g. a monitoring process that
looks the MM interfaces in DBus) to e.g. cut power to the device
completely (not in standard setups, though, this is more a custom
hardware setup thing usually) and the give it power back, forcing a
real full device reset.

But, for cases where the AT port is not the control one, we could
instead do something like trigger a full device reset using QMI/MBIM
to see if we can recover the AT port in that case. That would be
better than forgetting about the modem completely. But I understand
that this may also be not ideal because you may not want voice support
and you would prefer to just ignore the loss of the AT port and keep
the modem connected...

Anyway, as you also said, having lost the AT port may indicate other
kinds of internal problems, so attempting to trigger a reset ourselves
wouldn't be that bad in this case? I'm open to suggestions on how to
best handle this. Until now ModemManager hasn't done too many control
things "by itself", but I understand this may be one of those things
that could be automatically handled. It wouldn't be a bad idea to
start using a configuration file that would allow disabling these
smarts if needed.

-- 
Aleksander
https://aleksander.es


More information about the ModemManager-devel mailing list