ANN: ModemManager 1.18.4 released / Avoiding PPP

[Aleksander Morgado]

Hey,

>
> But there is no 100% fix. Certainly we can and should improve the
> probing and I'm happy to test that.  But with the PPP code in place,
> there's always going to be a code path where things didn't work
> out quite right with timing, or some error condition was triggered
> or whatever that will fall through.
>

Recovering some previous discussions in this email thread, I think
that updating mm_base_modem_organize_ports() so that it ends up with
no valid data ports flagged would probably the cleanest way to support
this usecase, if we want to do that. The method would fail with
"Failed to find a data port in the modem", in the very same way as QMI
or MBIM modems would fail if only the control port is detected. I'm
not a real fan of the fix, but we could do this by adding a new udev
tag as Dan suggested, e.g. named ID_MM_PORT_TYPE_AT_NO_PPP, so that we
can flag a TTY that must never be used for data (and you could apply
this tag to all your TTYs, effectively making the PPP option never
used). This is as dynamic as it can get; if you're happy with
ModemManager not exposing a modem object in DBus upon reaching that
situation, then let's add that, and it would save you from needing to
patch the PPP removal everywhere. What do you think?

> I don't have the luxury for waiting for improvement here, nor can
> I risk putting code in the field which might do this, no matter
> how tiny the chance, hence the removal of the PPP code entirely as
> a config option. I'm certainly not advocating stripping such
> support; that would be foolish.
>

Please make sure you pick the timing fix, so that the QMI ports are
always detected; that is the real fix, because you will make sure the
modem is exposed and usable, and you won't need any additional loop of
port event emissions added anywhere.

-- 
Aleksander
https://aleksander.es