ANN: ModemManager 1.18.4 released / Avoiding PPP

[Aleksander Morgado]

Hey Peter,

> >> # AWC EM12-AW
> >> #  ttyUSB0 (if #0): QCDM/DIAG port
> >> #  ttyUSB1 (if #1): GPS data port
> >> #  ttyUSB2 (if #2): AT primary port
> >> #  ttyUSB3 (if #3): AT secondary port
> >> ATTRS{idVendor}=="2c7c", ATTRS{idProduct}=="0512", ENV{.MM_USBIFNUM}=="00",
> >> SUBSYSTEM=="tty", ENV{ID_MM_PORT_TYPE_QCDM}="1"
> >> ATTRS{idVendor}=="2c7c", ATTRS{idProduct}=="0512", ENV{.MM_USBIFNUM}=="01",
> >> SUBSYSTEM=="tty", ENV{ID_MM_DEVICE_IGNORE}="1"
> >> ATTRS{idVendor}=="2c7c", ATTRS{idProduct}=="0512", ENV{.MM_USBIFNUM}=="02",
> >> SUBSYSTEM=="tty", ENV{ID_MM_DEVICE_IGNORE}="1
> >> ATTRS{idVendor}=="2c7c", ATTRS{idProduct}=="0512", ENV{.MM_USBIFNUM}=="03",
> >> SUBSYSTEM=="tty", ENV{ID_MM_DEVICE_IGNORE}="1"
> >>
> >
> > Should be ID_MM_PORT_IGNORE in all those (not DEVICE_iGNORE).
> >
>
> 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.

-- 
Aleksander
https://aleksander.es