ModemManager Delayed Signal Lost Disconnect on u-blox TOBY-R200

[Aleksander Morgado]

>
> > It's the modem firmware itself handling that, MM will just report
> > whatever the modem is reporting.
> >
> > E.g. if the modem is registered and connected in LTE, and the LTE
> > network disappears (e.g. low signal quality, out of coverage) then the
> > modem will try to handover to 3G or 2G transparently if there is any
> > 3G or 2G around. While this is happening, the modem will definitely
> > report that it's no longer registered in LTE (e.g. the CEREG:4 and
> > CEREG:0  you see in the logs), it will also probably say that it's
> > searching for some other non-LTE network via CREG/CGREG URCs, and
> > while all that is happening, the modem will still keep saying that
> > it's connected (the response to the periodic CGACT? states that the
> > PDP context / EPS bearer is still connected). ModemManager will say
> > that the modem is disconnected only when the CGACT? response reports
> > that our specific CID isn't active.
>
> What about the case I had in the original email where CREG, CGREG, and CEREG are all reporting 0 (idle) or 3 (registration denied).  At this point the modem is not searching anymore on 2G, 3G, or 4G.  Could this condition combined with a CSQ showing 0 signal strength be used to force a disconnect even though CGACT is still showing an active bearer?
>

I have a lot of mixed feelings about that; I don't think we should be
triggering any implicit disconnection ourselves if the modem didn't do
it itself. The connection stack inside the modem has much more info
than we do, and I would definitely prefer to just rely on the modem
doing the disconnection if one is needed.

> May  6 18:21:04 canect2 daemon.debug ModemManager[304]: <debug> [1557166864.178195] Modem /org/freedesktop/ModemManager1/Modem/0: signal quality updated (0)
> May  6 18:22:26 canect2 daemon.debug ModemManager[304]: <debug> [1557166946.511289] (ttyACM1): <-- '<CR><LF>+CREG: 0<CR><LF><CR><LF>+CGREG: 0<CR><LF><CR><LF>+CEREG: 0<CR><LF>'
>
> This change would make ModemManager more aggressive about disconnecting, but if NetworkManager has a profile configured for autoconnect, then the connection would reconnect as soon as the modem can reestablish registration on a valid network.
>

If that is your concern, leaving the modem to disconnect itself when
it thinks it should is probably going to give you the same
reconnection speed, if you think about it. If we trigger a
disconnection manually ourselves, we could even be doing things
*worse*, as we would ask the modem to disconnect a context with
CGACT=0 and the modem may end up taking a very long time to do that,
especially under low signal conditions. From my point of view, MM
shouldn't try to do anything on top of whatever the internal PS/EPS
stack is doing inside the modem.

> If this isn't something that you would want globally throughout ModemManager, then is this something that could be implemented in the u-blox plugin since it is u-blox's firmware that holds onto the bearer for a long time after loss of registration with the network?  If so, how would one modify that logic?  I would be willing to attempt to implement it but would like some ideas on where to properly implement the logic.
>

If you believe this is the u-blox firmware behaving incorrectly, then
we can definitely bring it to u-blox engineers.
Are you able to reproduce this issue easily with the TOBY-R200?
How much time have you seen the modem needing to report the context as
disconnected after all CREG/CGREG/CEREG keep saying 0? Are we talking
about seconds, minutes?

I'm not sure we want this in the u-blox plugin per se, again, not sure
if MM should try to be smarter than the modem with less information.

> I guess another approach would be to have an external application that uses the ModemManager library interface to monitor signal strength and registration status.  When the registration is lost and signal strength 0, then the external application could tell NetworkManager to stop the GSM connection profile.  In this case would the registration status be properly updated in the library as the connection is active?

That is totally up to you to do, yes, this would be totally doable and
it could be easy to do. BUT, consider again the case that trying to
disconnect cleanly involves CGACT=0 and that could end up taking a
very long time under low signal conditions...

>
> >
> > There's a thing here, though. For this kind of modems where PPP is
> > used, maybe we shouldn't be doing the periodic CGACT? checks through
> > the secondary TTY. This is an open point I have in mind to review,
> > because if we end up reporting the disconnection via MM (because CGACT
> > reports no active CIDs) then the pppd shutdown process may not be
> > happening properly in NM and the connected TTY may not go well back to
> > command mode. I think there was some open issue about this.
>
> I have reported a past issue where ModemManager is unable to reopen a port after a dropped cellular connection like this.  I am not sure it is the port that is the problem since just restarting ModemManager fixes the issue, so maybe it is something with the way ModemManager is keeping the state of the port.  If I remember correctly when ModemManager forced closed a port, it was not clearing its forced closed flag so ModemManager would always fail to open the port.  I think I only reported it in the mailing list but never filed a bug report in GitLab.  I could grab the old logs I have or possibly recreate the condition and file a new issue in GitLab if that would help track it.

That was the issue I believe.

-- 
Aleksander
https://aleksander.es