ANN: ModemManager 1.18.4 released / Avoiding PPP

[Aleksander Morgado]

Hey,

> > In the openwrt git master branch (which I believe it's what you're
> > using) that logic was updated to use a new wrapper script in
> > /usr/sbin/ModemManager-wrapper, and this scripts introduces a bogus
> > "sleep 2" in between the MM start and the call to
> > mm_report_events_from_cache:
> >
> >          /usr/sbin/ModemManager "$@" 1>/dev/null 2>/dev/null &
> >          CHILD="$!"
> >          sleep 2
> >          mm_report_events_from_cache
> >
> > I think that sleep is breaking the modem detection here, because the
> > realtime events are reported as soon as MM is detected, and the cached
> > ones are reported more than 2s later, and MM has a strict timing of
> > how long to wait for new port events since the last port event has
> > happened.
>
> The OpenWrt I'm using is a bit of a frakenstein, due to how I got to
> this point, but it's approximately 21.02 with some dev pieces. It could
> probably be rebased on 21.02, but that requires some effort.
>
> In any event, although I'm using latest MM (along with patches
> we've discussed), the packaging and scripts is very much like what's
> in 21.02 - I went through and double checked that there's no changes
> like this.  In any case, I don't have the wrapper script or the sleep 2.
>

Oh well; then the issue could be in the implicit wait done inside
mm_report_events_from_cache(), which has a loop with 1s in each loop.
If this timing is so tight that it affects how modem objects are
created, we may need to tweak the timing in the plugin probing
(EXTRA_PROBING_TIME_MSECS in mm-plugin-manager.c). I truly assumed you
were using the latest changes, because according to your logs the
cached events were reported approx 2s after MM started.

> As an aside, I went and turned off all the plugins except for quectel
> (this could be done for OpenWrt menuconfig, but that's another topic)

Yes.

> just to avoid confusion.
>

The device you're using will fall into a vid:pid fillter whitelist, so
there's not much room for error if you leave all the other plugins as
well.

> What I can see, is that even on an apparently successful connection,
> is there seems to be some confusion about what's available for ports,
> but I don't know enough about the mechanism to say if it's OK or not.
> I'll post a log of this shortly.

The list of available ports is decided during probing. If probing ends
with only 2 TTY ports (as in the log you posted earlier), then QMI
will be fully ignored and the net port will never be used. We really
need to fix the probing phase so that that doesn't happen. If you
could gather a MM debug log while reproducing the problem (not sure
how easy it is to reproduce) that would be awesome and much easier to
find where the true problem is.


-- 
Aleksander
https://aleksander.es