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 <pe...@chocky.org>
To: Aleksander Morgado <aleksan...@aleksander.es>
Cc: "ModemManager (development)" <modemmanager-devel@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.
