ANN: ModemManager 1.18.4 released / Avoiding PPP

[Aleksander Morgado]

Hey,

> > For a quick workaround in your case, can you try modifying
> > EXTRA_PROBING_TIME_MSECS in mm-plugin-manager.c and change it from
> > 1500 to something bigger like e.g. 3000 or 4000?
> >
> > There's one thing clear though; the longer timeout should not be
> > applied by default, as that would impose an extra wait time that is
> > not needed in most cases. I think we can make this more specific to
> > setups like yours, e.g. making the longer timeout happen only for
> > openwrt setups (when udev is not available) and also maybe applicable
> > only during MM daemon startup (e.g. if the port addition happened in
> > the first 10s of the MM daemon startup, allow a bigger extra probing
> > time). What do you think?
> >
>
> Yes, I will try this and look at some of the typical timings and see
> if something else is going on as an interim fix.
>
> However, it may always be the case that any timeout isn't "long enough";

But that is a problem that is inherent to how ModemManager works. MM
expects ports of the same device to be notified together; with a very
short time between each port notification. If this is not the case,
e.g. if the ports are notified with a very long time in between each
notification, MM may not grab all ports. At some point MM needs to say
"I no longer wait for more in this device", and that is achieved by
the timing setup hardcoded in MM itself, EXTRA_PROBING_TIME_MSECS is
one of the settings associated to that logic.

The best way to make this reliable so that no timeout is required
would be to have the kernel tell us how many different ports are going
to be exposed for the device, and then wait for the notification of
each; but that is not how the kernel works.

So removing the timing logic is not possible; but why not add an
extremely longer value that will definitely be safe? E.g. why not set
EXTRA_PROBING_TIME_MSECS  to 60000 to make it wait up to 1 minute in
between port additions in the same device? Well, if we wait so long,
the modem won't be exposed in DBus during all that time, so it's a
delay we introduce arbitrarily. Adjusting that timing to a safe enough
value needs to be considered.

MM could also "adjust" the already existing objects if new ports are
added once the modem has already been created, but that's a huge
functionality change that I don't even consider; the modem object
selection is done once we know the ports we have, so that we can e.g.
create a QMI-capable device, or just an AT-capable one instead. We
cannot change on the fly those objects if more ports in the device are
suddenly notified.

Another thing that MM could do is trigger a full modem object
recreation if new ports are emitted for an already existing device.
E.g. we got 2 TTY ports notified, we create an AT based modem, we then
get notified of a QMI+NET pair, and we could then flag the AT modem as
invalid and trigger a full reprobe from scratch so that the QMI port
is taken into account. That may be a bit easier to do actually.

> it's still critical to me that for my application I don't fall through to
> PPP; this needs to be failure case that I get notified about.
>
> It might be in the end that changes in detection assumptions are made,
> or that we have an option to strip PPP entirely from the build.

There would be multiple ways to do that; you could modify
mm_base_modem_organize_ports() so that it errors out when the data
port is a TTY; that would prevent the modem object from being created.
You could also modify the mm-broadband-bearer.c so that its creation
fails during a connection attempt; that would still leave the modem
object around, but it would fail if you try to connect it. It really
depends on what you expect to happen when PPP is assumed to be the
only data connection mode available.

-- 
Aleksander
https://aleksander.es