> -----Original Message----- > From: Aleksander Morgado [mailto:aleksan...@aleksander.es] > Sent: Tuesday, May 07, 2019 3:39 AM > > > > First what are the conditions where a cellular data connection will be > automatically disconnected due to bad signal/loss of network? Also what > program handles the disconnect (NetworkManager, ModemManager, > pppd)? > > > > 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? 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 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. 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? > > 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. > > -- > Aleksander > https://aleksander.es Best regards, Matthew Starr _______________________________________________ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
