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
