Re: Reconnecting GSM profile after a long period of no signal

On Tue, 2019-06-18 at 22:58 +0000, Matthew Starr wrote:
I am running NetworkManager 1.12.0 on an embedded Linux device that
has Ethernet, Wi-Fi, and cellular.  I am seeing a connection issue on
GSM profiles that are setup for autoconnect=true.  If I am able to
establish a connection on cellular, then lose signal (move out of
range) for 20-60 minutes, and then come back within range of the
cellular signal, NetworkManager will not attempt to reconnect to
these networks.  I can see that ModemManager (version 1.8.0) is fully
registered with the cellular network and that NetworkManager is just
not requesting to connect a data session.
I know NetworkManager has a 300 second autoconnect reset retry
timer.  I modified that timeout to be 60 seconds to make
NetworkManager more aggressive on retry attempts. I have given
NetworkManager over an hour and have seen no attempt to connect to
the cellular network after a long period of no signal.  A simple
“nmcli con up <PROFILE>” command will instantly connect when run, but
I want NetworkManager to automatically connect without user
intervention on the command line.
I believe I had someone explain before that this is based on the
logic of a connection that is having issues with getting data is
eventually assumed to be a bad connection after enough failed
attempts and that knowledge is somehow stored somewhere so
NetworkManager doesn’t try to connect to that network again.  In my
case I have an embedded device that is attached to mobile assets so
the cell and Wi-Fi signal will come and go, the whole time the device
is never turned off.
I have also seen this issue with Wi-Fi previously, but I am not sure
if that is the same issue I am seeing now with cellular.
Is there some way to force NetworkManager to always keep retrying to
connect to networks defined in profiles that have autoconnect set to
true until successfully connected, no matter how many times it fails
to connect?


when NetworkManager thinks that the connection failure happend due to a
bad pin, then it might block autoconnect indefinitely. That is to
prevent blocking the pin.

Another reason why autoconnect be blocked is if NetworkManager thinks that the secret
(Pin) was wrong, but there is no secret-agent around to provide a secret.

But probably something is not right here. What does the level=TRACE log say about
this? See [1] for infos about logging, in particular about rate-limiting.



Attachment: signature.asc
Description: This is a digitally signed message part

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]