Re: spamming router with router solicitations



On Sat, 2019-06-01 at 07:00 -0400, Brian J. Murrell wrote:
On Thu, 2019-05-30 at 12:23 +0200, Thomas Haller via networkmanager-
list wrote:
On Wed, 2019-05-29 at 12:23 -0400, Brian J. Murrell wrote:
On Wed, 2019-05-29 at 09:28 +0200, Thomas Haller via
networkmanager-
list wrote:
If this is happening, when you kill NetworkManager with
SIGKILL,
it
would not give NetworkManager to cleanup...

  sudo killall -SIGKILL NetworkManager

(and veryify that NetworkManager is indeed not running. Maybe
first
`systemctl mask NetworkManager`, so that systemd won't restart
it).

Are you suggesting that I kill NM with SIGKILL as a debugging
step
to
see if the RSes still stop when stopping NM?

Yes.

If so, that was an interesting experiment:

# killall -SIGKILL NetworkManager
# ps -ef | grep Network
root     15001     1  0 12:02 ?        00:00:00
/usr/sbin/NetworkManager --no-daemon

So clearly systemd restarted it, but it's not flooding RSes after
the
restart.

Ah ok. That's what I meant with first masking NetworkManager.

# systemctl mask NetworkManager
Created symlink from /etc/systemd/system/NetworkManager.service to
/dev/null.
# killall -SIGKILL NetworkManager
# systemctl status NetworkManager
‚óŹ NetworkManager.service
   Loaded: masked (/dev/null; bad)
   Active: failed (Result: signal) since Sat 2019-06-01 06:53:23 EDT;
39s ago
 Main PID: 4286 (code=killed, signal=KILL)

May 31 22:04:18 server.example.com NetworkManager[4286]:
<info>  [1559354658.5223] manager: NetworkManager state is now
CONNECTED_SITE
May 31 22:04:18 server.example.com NetworkManager[4286]:
<info>  [1559354658.5274] policy: set 'enp2s0' (enp2s0) as default
for IPv6 routing and DNS
May 31 22:04:18 server.example.com NetworkManager[4286]:
<info>  [1559354658.5670] device (enp2s0): Activation: successful,
device activated.
May 31 22:04:18 server.example.com NetworkManager[4286]:
<info>  [1559354658.5807] manager: NetworkManager state is now
CONNECTED_GLOBAL
May 31 22:04:18 server.example.com NetworkManager[4286]:
<info>  [1559354658.5934] manager: startup complete
May 31 22:04:33 server.example.com NetworkManager[4286]:
<info>  [1559354673.1941] policy: set 'enp2s0' (enp2s0) as default
for IPv4 routing and DNS
Jun 01 06:53:09 server.example.com systemd[1]: Current command
vanished from the unit file, execution of the command list won't be
resumed.
Jun 01 06:53:23 server.example.com systemd[1]:
NetworkManager.service: main process exited, code=killed,
status=9/KILL
Jun 01 06:53:23 server.example.com systemd[1]: Unit
NetworkManager.service entered failed state.
Jun 01 06:53:23 server.example.com systemd[1]: NetworkManager.service
failed.

Before killing NM, it was flooding out RSes and after killing it it
stopped.

Thanks, that's of course a string indication that NetworkManager is the
culprit.

But I don't see how.

NetworkManager uses libndp for NDP. There is only one place where it
sends RS, and thereby it also should log a debug message:

[1] 
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/blob/8964dbe8bc9cbe7300a48bffe86faee6b149fbf2/src/ndisc/nm-ndisc.c#L555

I did not see these messages...

Just to check, did you enable level=TRACE logging and made sure that a
possible burst of logging messages is not rate limited by systemd-journald?
See the comments at

[2] https://cgit.freedesktop.org/NetworkManager/NetworkManager/tree/contrib/fedora/rpm/NetworkManager.conf#n28

about that. Then, in the logfile I presume you do not see the messages
about "router solicitation". So, it's unclear how these messages get
sent.


Maybe the issue is in libndp, but that should also just send one
message

[3] https://github.com/jpirko/libndp/blob/98bdaa1cb94faff0ccf992abc40a352ea16640fa/libndp/libndp.c#L195

... unless kernel wrongly fails with errno EINTR, which seems unlikely.
It would be interesting to see if this goes away by setting "errno =
0;" right before sendto() in [3].


No ideas so far.


How is the CPU usage of NetworkManager when this happens?


best,
Thomas




If you kill NetworkManager with SIGKILL (without letting
NetworkManager
restart), it would not give NetworkManager time to do anything.
If that stops the flodding, then the messages were sent by
NetworkManager -- otherwise not.

Indeed.

Thanks. It would be most interesting to see them at the moment when
the
flodding happen.s

Damn.  I should have gathered these before killing NM because now
that
I have and have restarted it, it's not flooding again.

I will update here the sysctl content when I see it flooding again.

Cheers,
b.

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

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]