cinterion: Question about udev rules

[Aleksander Morgado]

Hey,

> I'm working with a cinterion, PLS62W module and using PPP. One of the
> issues I run into is that in certain scenarios, like sudden loss of
> registration(due to poor signal) where MM disconnects the bearer, the
> primary data port (and at port) ttyACM0 becomes unusable.
> I think somehow MM and the pppd were trying to use the port at the
> same time, as a result I end up getting an object removed signal
> because MM can't talk to the modem anymore and I end up having to
> power cycle the modem.
>

What ModemManager version is this?
Are you also using NetworkManager and therefore pppd is launched by
NM? Or do you have your own setup?


> I was going to add a line to call ppp_off as part of the ppp script.
> disconnect /etc/ppp/scripts/ppp_off.sh
>

I'm not sure what's that for really, so cannot comment on that.

What I can say is, if your modem has the same port as AT primary port
and for PPP, ModemManager and the upper layers MUST be synchronized in
the access of the TTY. As soon as MM reports the modem connected, it
must stop using it; and as soon as the upper layers tell MM that the
modem is disconnected (because pppd exited) then MM can recover the
control to the port. If both pppd and MM are trying to use the TTY at
the same time, this is not happening. I asked about the MM version
because there was a "bug" (feature originally) where MM would
auto-detect disconnections via +CGEV events and if so it would attempt
to use the TTY even if pppd didn't release it yet. This was fixed some
time ago for PPP-based modems (it wasn't an issue if a net port wasn't
being used).

> In addition another suggestion given to me was to declare ttyACM1 as
> the primary and ttyACM0 as the PPP port
>
> ATTRS{idVendor}=="1e2d", ATTRS{idProduct}=="005b",
> ENV{.MM_USBIFNUM}=="00", ENV{ID_MM_PORT_TYPE_AT_PPP}="1"
> ATTRS{idVendor}=="1e2d", ATTRS{idProduct}=="005b",
> ENV{.MM_USBIFNUM}=="02", ENV{ID_MM_PORT_TYPE_AT_PRIMARY}="1"

Yes, this is another way to handle this problem, by making sure that
the port MM uses for control (the primary port) is different to the
one that would be used for data (the ppp port). In this case, the
chances of breaking something are much less, because MM only uses the
PPP port during the dialing sequence. But you can only do this if the
modem doesn't care about running PPP over that other port; some modems
have specific ports for different things.

> ATTRS{idVendor}=="1e2d", ATTRS{idProduct}=="005b",
> ENV{.MM_USBIFNUM}=="04", ENV{ID_MM_PORT_IGNORE}="1"
> ATTRS{idVendor}=="1e2d", ATTRS{idProduct}=="005b",
> ENV{.MM_USBIFNUM}=="06", ENV{ID_MM_PORT_IGNORE}="1"
> ATTRS{idVendor}=="1e2d", ATTRS{idProduct}=="005b",
> ENV{.MM_USBIFNUM}=="08", ENV{ID_MM_PORT_IGNORE}="1"
> ATTRS{idVendor}=="1e2d", ATTRS{idProduct}=="005b", SUBSYSTEM=="net",
> ENV{ID_MM_PORT_IGNORE}="1"
> ATTRS{idVendor}=="1e2d", ATTRS{idProduct}=="005b",
> SUBSYSTEM=="usbmisc", ENV{ID_MM_PORT_IGNORE}="1"
>

Out of curiosity now, why are you ignoring the NET and MBIM ports?
Using them would be much better than the AT+PPP pair!

> Any negative impact because of this ? I ran basic sanity and things
> seem ok (was still getting periodic connection checks/signal
> status/extended signal reports).
> But since I hadn't seen too many plugins use this thought I'd check
> first before making that change.

There shouldn't be any negative impact on adding those udev rules; but
remember that the actual issue is that MM and pppd are out of sync,
and that may be because you're using an old MM+NM setup.

The suggestion to use the MBIM+NET pair instead of AT+PPP still stands
over any other suggestion :)
--
Aleksander
https://aleksander.es