ANN: ModemManager 1.18.4 released / Avoiding PPP

[Aleksander Morgado]

Hey Dan!

> > > > 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.
> > >
> > > I don't want PPP, ever.  I don't know how many times I can repeat
> > > that.  Please stop saying this and arguing with me about it.
> > >
> >
> > I know you don't want PPP in your setup, you have made that clear.
> > I'm
> > not arguing with you about that. I get it. You don't want PPP.
>
> Yeah, MM has to work for a lot of people, some who want PPP and many
> who don't. But there's still enough PPP going around that it must
> continue to be supported for a while.
>

Plus, I don't think this is something we can just optionally remove
from the build, just the PPP part. This is not like QMI or MBIM where
we can disable the full QMI or MBIM protocol, both control and data.
The equivalent thing would be to fully disable AT+PPP; but just
disabling PPP is not a good idea IMO, because we could end up leaving
not-connectable AT-only modems around (unless we want to allow such a
thing)

> >
> > Now, the way to fix that should be by making sure ModemManager gets
> > notified of the QMI/NET port before it creates a modem object only
> > with TTY ports. I understand that you don't like this approach, but
> > ModemManager doesn't receive a fixed list of ports to work with, as
> > many other modem management setups. MM tries to dynamically adjust to
> > what it finds, and that is a core feature of ModemManager that is not
> > going to change.
>
> In the past IIRC we've seen bad udev rules or scripts taking multiple
> seconds to evaluate or do something (I think usb_modeswitch was a
> problem here once upon a time) and delaying updates for specific ports
> of a device. Not sure if that's a problem here, or if the system is
> just slow.
>

The problem is the system being slow plus needing mmcli to report the
kernel events when openwrt hotplug scripts are run, which make it even
slower. This issue won't apply to udev based systems, I think it's
applicable only to openwrt.

> >
> > So again, and don't hate me for repeating this, if MM gets notified
> > of
> > one single AT capable TTY port and nothing else, it will default to
> > use PPP. If you don't like that, please patch your ModemManager to
> > fit
> > your needs. Or try moving to uqmi, which requires you to specify
> > which
> > is the cdc-wdm port path explicitly, although that approach has its
> > own problems, but maybe not the ones you're worried about.
>
> I haven't read the whole thread in detail, so forgive me if this was
> covered. Perhaps a way of tagging a modem/driver/whatever with "never
> use PPP" would be workable. Off by default of course.
>

The problem with that is what you do when you have a modem exposed
with one single AT port, which is what ended up happening in Peter's
setup. Do we expose the modem in DBus but not connectable? Do we
expose it in Failed state? Do we just not expose the modem in DBus?
The problem here is not a QMI+AT modem that sometimes falls back to
PPP; the problem here is an AT-only No-QMI (because it failed probing)
modem that falls back to PPP.

My suggestion has always been to fix the probing logic so that the QMI
ports are properly detected always; and once that is done and is
reliable, there would be no need to take care of whether PPP is used
or not, as QMI would always be preferred. PPP is only the fallback if
QMI is unusable for any reason. Trying to remove PPP without fixing
the probing logic leads nowhere. And once probing logic is fixed,
removing PPP would not be needed.

-- 
Aleksander
https://aleksander.es