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

[Thomas Haller <thaller redhat com>]

On Tue, 2019-06-25 at 19:07 +0000, Matthew Starr wrote:
> > -----Original Message-----
> > From: Thomas Haller [mailto:thaller redhat com]
> > Sent: Thursday, June 20, 2019 3:22 AM
> >
> > 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?
> >
> > Hi,
> >
> > 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.
> >
> > [1]
> > https://cgit.freedesktop.org/NetworkManager/NetworkManager/tree/cont
> > rib/fedora/rpm/NetworkManager.conf#n28
> >
> >
> > best,
> > Thomas
>
> Thomas,
>
> I have had the condition where NM does not attempt to reestablish a
> data connection a few times, but now that I am trying to reproduce
> it, to get better logs, it isn't happening.  I will keep trying.
>
> Where in the NM code is the logic blocking autoconnect indefinitely
> when an autoconnect profile is repeatedly not able to connect?

Hi,

on master,

  $ git grep nm_settings_connection_autoconnect_


> In my use case of an embedded device, I always want to retry even if
> it wasn't working previously.  I am considering making my own
> modifications to disable blocking autoconnect indefinitely.  Maybe
> this could lead to a configuration option to enable/disable this
> logic.


best,
Thomas

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