Detection failure with 1.20.4

[Peter Naulls]

On 2/7/23 06:18, Aleksander Morgado wrote:
> Hey,
> 

>>
>> In this log, I've disabled PPP, and out of desperation, DHCP too, to limit
>> the churn.  This problem appears 100% of the time at start up, and is only
>> resolved by a restart of ModemManager, or a cycling of the USB interfaces
>> (which the top-level monitoring script will eventually do, but takes some
>> minutes in practice).
>>
>> The misdetection can happen on the legacy platform, but having disabled PPP
>> and extra plugins it seems to be pretty rare.
>>
>> Let me know if there's extra debug I can provide.
>>
> 
> The misdetection will happen regardless of whether you disable PPP or
> other plugins, because it depends exclusively on how quick the ports

Understood. Still, failing over to PPP or DHCP is never going to be the
answer in the very occasional cases that detection might fail due to
factors beyond our control.

I appreciate that my setup is very specific to my needs, but still.


> The "extra probing time" is the amount of time ModemManager waits for
> a port to be notified since the last port notification on the same
> device. For openwrt this is 3 seconds (1.5s when using udev), see
> https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/blob/main/src/mm-plugin-manager.c#L726

Understood. I have increased to 4 seconds. There is still some churn at
start which I need to take a look at, but this is probably going to be good
enough for now, and connecting within one minute of boot is acceptable.

> Another way to approach this issue would be by forcing a full device
> reprobe if we end up finding new ports added after we decided there
> may not be more notified, as in your case. I believe I already tried
> to do something like that months ago when we first discussed your
> issues, and I drafted a patch, but which is totally untested and may
> actually not work at all, here:
> https://gitlab.freedesktop.org/aleksm/ModemManager/-/commit/1ac4b7099b8835599f9131bf9f2ef6a7964c09ed
> Would be good to revisit that approach maybe, as it would be
> independent of the timing.

That seems like a wise thing to do - nothing of course here is going to be 
perfect, but I'd agree with this logic. I am now running with this patch and 
we'll see how things going.

Thanks again.