ANN: ModemManager 1.18.4 released / Avoiding PPP

[Aleksander Morgado]

Hey Peter,

> >> I see. So the problem is that I have to keep port 02 open for mmcli commands,
> >> but if I do it'll try to use this for PPP still sometimes.
> >>
> >
> > Please note that the reason to use PPP is not that MM sometimes
> > prefers it over QMI+NET. If PPP is being used, it's likely because the
> > QMI port failed to be probed successfully, so AT+PPP is the only
> > option left. The failure in the QMI probing could be a limitation of
> > the probing logic, or the modem firmware getting fully stuck, or
> > something in between (e.g. maybe a given modem boot took longer than
> > usual and we failed probing while waiting for it to work properly).
> > Debug logs will tell you in detail why PPP is chosen instead of
> > QMI+NET.
> >
>
> Well, I didn't dig into the debug, but I understand why it's falling back
> and that QMI/driver is not ready yet - it doesn't matter though; I need this
> to be a failure case (and then fall through to retry). PPP is not a credible
> option in my setup, and will just cause a longer connect cycle, since it'll
> fail later on.
>
> On the flip side, I understand the rationale for the general case here.
>
> This is what I ended up using as a local patch, which should be obvious:
>
>   --- a/src/mm-base-modem.c.orig        2022-01-04 09:50:31.631768015 -0500
> +++ b/src/mm-base-modem.c       2022-01-04 09:46:08.183807331 -0500
> @@ -387,9 +387,9 @@
>               } else if (mm_kernel_device_get_property_as_boolean
> (kernel_device, ID_MM_PORT_TYPE_AT_SECONDARY)) {
>                   mm_obj_dbg (port, "AT port flagged as secondary");
>                   at_pflags = MM_PORT_SERIAL_AT_FLAG_SECONDARY;
> -            } else if (mm_kernel_device_get_property_as_boolean (kernel_device,
> ID_MM_PORT_TYPE_AT_PPP)) {
> +/*            } else if (mm_kernel_device_get_property_as_boolean
> (kernel_device, ID_MM_PORT_TYPE_AT_PPP)) {
>                   mm_obj_dbg (port, "AT port flagged as PPP");
> -                at_pflags = MM_PORT_SERIAL_AT_FLAG_PPP;
> +                at_pflags = MM_PORT_SERIAL_AT_FLAG_PPP;*/
>               }
>           }
>           /* The plugin may specify NONE_NO_GENERIC to avoid the generic
>
>
> Maybe this should be a command line option or something, up to you.
>

Please note, that patch is not completely disabling the PPP usage,
it's just disabling the PPP port type hint. If ModemManager detects AT
ports and no valid QMI+NET port, it will still use PPP over the tty on
the detected AT port. By disabling the port type hint, you're removing
the association of which explicit port should be used for PPP data,
and that means MM may try PPP over a serial port that it's not
prepared for that.

Also, please note that if you fully disable the PPP usage (maybe
making sure that data_at_primary is always NULL in
mm_base_modem_organize_ports()), what you will achieve is that the
modem ends up not usable ("Failed to find a data port in the modem").
You need to decide whether that's better than falling back to PPP. As
said in an earlier email, the key would be to understand why you don't
have a valid QMI+NET pair, not really to disable the PPP usage (IMO).

> As for ID_MM_PORT_IGNORE, I had to pull those out - it seems that
> once ModemManager connects, it's no longer possible to use mmcli - I didn't
> try to dig down into this detail, but it was problematic in our testing.
>

Not sure what you mean with this, mmcli is completely independent from
the connection state. What mmcli command failed?

-- 
Aleksander
https://aleksander.es