Reconnecting GSM profile after a long period of no signal

[Matthew Starr]

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 " 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?

Best regards,
Matthew Starr

___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: spamming router with router solicitations

[Brian J. Murrell]

On Mon, 2019-06-03 at 14:17 -0400, Brian J. Murrell wrote:
> 
> I think I had it set to DEBUG.  Let me see if I can reproduce with it
> set to TRACE.

I have to correct myself.  It was set to TRACE.

> It goes up quite a bit.  More indication that it is NM.

CPU is pegged between NM, journald and one other unrelated process.  I
assume without the latter, NM and journald would monopolize the CPU.

So I don't really know what's going on here.

But really, given all of the time I have spent on this, the path of
least resistance is probably just rate-limiting the RSes at the router.

What's a reasonable number of RSes to allow in a given time-frame?

1/sec burst 5 seems to be keeping things under control on both the
router and the machine suffering this NM problem.

Probably worth mentioning that the NM version on Fedora doesn't have
this problem.

Cheers,
b.



signature.asc
Description: This is a digitally signed message part
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list