ANN: ModemManager 1.18.4 released / Avoiding PPP

[Aleksander Morgado]

Hey Peter,

> > 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.
>
> No. and this is my annoyance with "waiting" in general, and this issue
> specifically that I've repeated here many times already. There is no
> value which is "long enough".
>
> An arbitrarily high value is going to cause problems, but it must be
> long enough that it's caught most of the time.
>
> *BUT* if there's some situation where there's a disconnect, external
> reset or other condition where the second port is not detected or it's
> simply taking "too long", (and I promise you, such situations can and
> do occur), then falling back to PPP is not any kind of solution, ever.

What's the solution then, when ModemManager doesn't know which kind of
modem it's going to manage. You know you have a QMI modem, MM doesn't
know it's a QMI modem until it has found a valid QMI+NET pair and has
made sure it works.

The way MM works is that it decides the type of connection setup to
use based on the ports that have been detected. And for that it needs
to know when all ports have been reported by the kernel, and we have
timing logic associated for that. We can improve that timing logic, or
we could even update MM to force a full reprobe of the device when new
ports have been detected on an already existing modem, but the core
logic is not going to change.

If MM detects a single TTY port, it's going to default to use PPP.
It's not a fallback to PPP, it's using whatever it has for data
connection, if PPP is the only way forward, PPP will be.

>
> >
> > 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;
>
> I guess I will attempt that.
>

Ok.

> > It really depends on what you expect to happen when PPP is assumed to be the
> > only data connection mode available.
>
> Maye it's your English, but I don't want to get to this assumption.
>

English is not my main language, so it may be that I'm not explaining
clearly enough, sorry if that's the case. I could also try to explain
in Spanish or Basque if you prefer, but I don't think it would improve
much :)

> It's too late at that point.

Yes, the error when the connection attempt is triggered is probably
too late, I also agree with that. I was just giving you options.

> Like I said, pretty tired of arguing this point.
>

I acknowledge we have different point of views; but please, try
updating the EXTRA_PROBING_TIME_MSECS value to 3000ms, so that we
don't miss the QMI port notifications. If MM detects valid QMI+NET
ports, it won't try PPP.

Cheers!

-- 
Aleksander
https://aleksander.es