ANN: ModemManager 1.18.4 released / Avoiding PPP

[Dan Williams]

On Tue, 2022-01-18 at 09:57 +0100, Aleksander Morgado wrote:
> 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)

Yeah, I don't think it should be removed entirely; it's really not a
lot of code over-and-above AT itself. Which is still used for a *lot*
of stuff.

> 
> > > 
> > > 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.

Ah, ok.

> 
> > > 
> > > 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.

I'd just expose the modem as failed and let the
admin/framework/whatever handle it by power-cycling the modem or
machine. If we didn't expose it then it would be more complicated with
timeouts or something on whatever is above MM.

> 
> 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.

Yeah, clearly if we can fix or work around slow probing, that's
preferable.

Dan