Extending OpenWRt ModemManager protocol handler

[Aleksander Morgado]

Hey Peter,

> > That's not really true, because that timeout is bound to the max time
> > required by ModemManager to probe the AT/QMI/MBIM ports, which I
> > believe is close to those 45s max per port (in parallel). Having an
> > infinite loop there doesn't help, as that max time required by MM is
> > not arbitrary, that's why I suggested incresing the timeout value;
> > maybe some of the ports take up to 45s to probe and we just need a
> > longer timeout when detecting the modem in DBus.
> >
>
> Honestly, I'm a bit tired of these around and around debates with you. I think
> you like to argue a bit too much, and it's off-putting in trying to contribute.
>

Oh, that is completely not my intention, and if you felt it that way,
I'm __extremely__ sorry. Please, keep on sending emails, and please
bear with my replies, and please never assume I'm trying to argue just
for the sake of it, not my intention at all.

> Let's be very clear here - there are situations that ModemManager/netifd
> will simply timeout and then no longer attempt any connection.

There are **a lot** of such scenarios, I totally acknowledge that, and
from my point of view most (all?) those scenarios are due to the lack
of sync between netifd and MM, as per
https://bugs.openwrt.org/index.php?do=details&task_id=3499. I'm not
trying to open any debate here, I totally acknowledge that lack of
sync will break connectivity easily; e.g. netifd thinking the
interface is connected while MM knows the interface is not connected
(and with no way to report that back to netifd). Until that is fixed
in netifd, we'll need additional programs to monitor the modem
connection and trigger netifd interface updates accordingly (e.g. if
we see the bearer disconnected in MM but the interface up in netifd,
bring the interface down and reconnect).

> This was
> a serious problem for us that it took a long time to find.  This is the
> fix I came up with which resolves that.  I reported this early last year
> and it was dismissed.

Was that patch sent against the ModemManager package in
openwrt-packages (https://github.com/openwrt/packages/issues)? Or just
in this mailing list?

>
> If you want to argue the mechanism, or do a better fix, then fine. But
> this is a very real problem.
>

I'm sure that was a very real problem, I don't argue, but I'm just
suggesting a different way to fix it because of how the port probing
timing works in ModemManager, which isn't arbitrary and isn't
infinite. MM stops probing the ports at some point, and by the time
the last port probing has finished, the modem either gets exposed on
DBus (so the wait succeeds) or not (so the wait must fail).
Unfortunately we don't expose in DBus an event saying "we were probing
modem at sysfs path XXX but the port probing failed and no modem is
exposed in DBus"; if we had that event we could completely remove the
timeout in mm_wait_for_modem(), but as we don't have the event, we
configure a timeout slightly longer than the max probing time. Adding
an infinite loop in mm_wait_for_modem could render that process
waiting forever :/ If I'm suggesting a different way to handle the
issue you tried to fix is because the way I'm suggesting may be
simpler, and simpler to integrate in the openwrt package (which, BTW,
I don't really maintain myself, Nick is doing that).

--
Aleksander
https://aleksander.es