Re: spamming router with router solicitations

[Beniamino Galvani via networkmanager-list]

On Tue, Jun 25, 2019 at 10:20:54AM -0400, Brian J. Murrell wrote:
> On Mon, 2019-06-24 at 08:52 +0200, Beniamino Galvani via
> networkmanager-list wrote:
> > 
> > Hi,
> 
> Hi Beniamino,
> 
> > I checked again the log you sent and I see the problem now. When NM
> > receives a RA, it checks whether the parameters
> 
> Which parameters exactly?  Because I might be able to shed some light
> on this now that this is known.

Basically everything in the RA. See how the 'changed' variable is set in:

https://gitlab.freedesktop.org/NetworkManager/NetworkManager/blob/1.18.0/src/ndisc/nm-lndp-ndisc.c#L110

> > changed compared to
> > the previous RA and if so it applies the new configuration. When it
> > does so, it also reapplies the token; this triggers a new router
> > solicitation from kernel due to:
> > 
> >   
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/net/ipv6/addrconf.c?h=v3.10#n4336
> 
> Interesting.
> 
> > The new RA received is:
> > 
> >   neighbor discovery configuration changed [R]:
> > dhcp-level none
> > gateway fe80::6eb0:ceff:fef5:1e4a pref high exp 1799.2317
> > address 2001:123:ab:123::2 exp permanent
> > route 2001:123:ab:123::/64 via fe80::6eb0:ceff:fef5:1e4a pref
> > high exp permanent
> > dns_server fd31:aeb1:48df::2 exp 7199.2317
> > 
> > Note the "changed [R]" part which means that routes changed. This is
> > strange because according to log there was no change from previous
> > RA. This causes the reapply of token, a new RS, a RA and so on ...
> 
> Here is what an RA from my router looks like:
>
> [...]
>
> But three things that the above is not saying:
> 
>1. Until yesterday, the Router Lifetime of one of those RAs was 0 and
>   the other was 1800 (I don't recall which was which).
>2. Until the last week or two, the first prefix was being advertised
>   with a Router preference of high and the other was medium.
>3. Each of those two RAs come in two different packets, one for each
>   prefix rather than them both being in the same RA which I think is
>   the typical behaviour.

I think all these should be handled well. But perhaps older versions
of NM had issues with the 0 lifetime of point 1.

> > Apart from this, I think NM should not apply the token when it's
> > already set;
> 
> That seems reasonable.

This is now fixed in master:

 
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/commit/e4ce9bd7af6a39677ff1a1380906d18062abb24a

and stable branches nm-1-18, nm-1-16.

Beniamino


signature.asc
Description: PGP signature
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

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

[Thomas Haller via networkmanager-list]

On Tue, 2019-06-25 at 19:07 +, Matthew Starr wrote:
> > -Original Message-
> > From: Thomas Haller [mailto:thal...@redhat.com]
> > Sent: Thursday, June 20, 2019 3:22 AM
> > 
> > On Tue, 2019-06-18 at 22:58 +, 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 ”
> > > 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


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