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