Extending OpenWRt ModemManager protocol handler

[Enrico Mioso]

In other words, I think the current situation isn't going to change so soon.
So I was wondering if we can provide a kind of short-cut, so the protocol handler examines all bearers it finds, skipping all the modem device management.
This would allow the code to be re-usable.

What do you think?
Would this solution be acceptable to you?

On Mon, 10 Jan 2022, Aleksander Morgado wrote:

> Date: Mon, 10 Jan 2022 15:44:09
> From: Aleksander Morgado <aleksander at aleksander.es>
> To: Peter Naulls <peter at chocky.org>
> Cc: "ModemManager (development)" <modemmanager-devel at lists.freedesktop.org>
> Subject: Re: Extending OpenWRt ModemManager protocol handler
> 
> 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
>