Extending OpenWRt ModemManager protocol handler

[Enrico Mioso]

thanks a lot Aleksander for the help and assistance.




On Mon, 10 Jan 2022, Peter Naulls wrote:

> Date: Mon, 10 Jan 2022 15:04:51
> From: Peter Naulls <peter at chocky.org>
> To: Aleksander Morgado <aleksander at aleksander.es>
> Cc: "ModemManager (development)" <modemmanager-devel at lists.freedesktop.org>
> Subject: Re: Extending OpenWRt ModemManager protocol handler
> 
> On 1/10/22 9:00 AM, Aleksander Morgado wrote:
>> Hey,
>
>> 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.
>
> Let's be very clear here - there are situations that ModemManager/netifd
> will simply timeout and then no longer attempt any connection. 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.
>
> If you want to argue the mechanism, or do a better fix, then fine. But
> this is a very real problem.
>
>

I think we are talking about two unrelated thing: I was trying to keep the system persistently connected, so I am assuming detection worker properly.

That said, thanks Aleksander for the pointer and hint.
However, it would be nice if we could have some way to let it work right now: I would need the protocol handler to just examine connected bearer(s) and configure them.
I would "refresh" it via the helper script invoking
ifup
somehow.