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
