Bug #10939

NetworkManager spams logs with IPv6 router solicitation failure for the default wired connection

Added by emmapeel 2016-01-14 12:07:28 . Updated 2016-01-27 13:33:44 .

Status:
Resolved
Priority:
Normal
Assignee:
Category:
Target version:
Start date:
2016-01-14
Due date:
% Done:

100%

Feature Branch:
bugfix/10939-IPv6-log-spam
Type of work:
Research
Blueprint:

Starter:
Affected tool:
Deliverable for:

Description

With Tails 2.0rc1 I get a lot of:

Jan 14 11:56:14 amnesia NetworkManager[5659]: <error> [1452772574.043792] [rdisc/nm-lndp-rdisc.c:241] send_rs(): (wlan0): cannot send router solicitation: -1.

but the network works as usual.


Subtasks


History

#1 Updated by intrigeri 2016-01-14 13:24:05

  • Category deleted (Hardware support)

#2 Updated by intrigeri 2016-01-14 13:38:12

  • Subject changed from NetworkManager spams logs with error (wireless works ok) to NetworkManager spams logs with IPv6 router solicitation failure
  • Status changed from New to Confirmed
  • Assignee set to intrigeri
  • Target version set to Tails_2.0

This is caused by NM enabling IPv6 on all interfaces by default, while our firewall blocks IPv6. Random ideas/thoughts:

  • for the default wired connections, we could maybe disable IPv6 in config/chroot_local-includes/etc/NetworkManager/system-connections/ (method=ignore in the [ipv6] section); but this won’t address manually added connections, such as Wi-Fi
  • perhaps explicitly rejecting IPv6 packets in the firewall, instead of silently dropping them, would avoid such noise in the logs
  • one should check if it’s doable to disable IPv6 globally in NM; I’d rather not patch it to do so.

I’ll give a quick try to fix it cheaply for 2.0.

#3 Updated by intrigeri 2016-01-14 13:49:24

> * for the default wired connections, we could maybe disable IPv6 in config/chroot_local-includes/etc/NetworkManager/system-connections/ (method=ignore in the [ipv6] section); but this won’t address manually added connections, such as Wi-Fi

Tested, I confirm it works for the default wired connection.

> * perhaps explicitly rejecting IPv6 packets in the firewall, instead of silently dropping them, would avoid such noise in the logs

We’re actually rejecting them explictly already. I should try silently dropping these specific ICMPv6 packets.

> * one should check if it’s doable to disable IPv6 globally in NM; I’d rather not patch it to do so.

Another idea could be to configure NM’s logging to not log anything related to IPv6. Apparently one can configure “per-domain log level” (NetworkManager.conf(5)).

#4 Updated by intrigeri 2016-01-14 14:04:41

> Another idea could be to configure NM’s logging to not log anything related to IPv6. Apparently one can configure “per-domain log level” (NetworkManager.conf(5)).

This won’t work: the log messages we’re talking of are of the highest level (error), and there seems to be no way to silence these.

#5 Updated by intrigeri 2016-01-14 14:11:04

> > * perhaps explicitly rejecting IPv6 packets in the firewall, instead of silently dropping them, would avoid such noise in the logs
>
> We’re actually rejecting them explictly already. I should try silently dropping these specific ICMPv6 packets.

Dropping does not change anything. Rejecting with icmp6-adm-prohibited or icmp6-no-route doesn’t either. Solving this via the firewall seems to be a lead that won’t work.

#6 Updated by intrigeri 2016-01-14 14:12:50

My conclusion so far is: it’s trivial to fix this problem for the default wired connection, but short of patching NM to disable IPv6 for all connections by default, I don’t see how to fix it for other connections.

#7 Updated by intrigeri 2016-01-14 14:18:33

Another (crazy?) idea: add a NM dispatcher hook that turns off IPv6 for the active connection, e.g. with nmcli con modify $CONNECTION_ID ipv6.method ignore. I’ve tried this outside of the dispatcher, and it modifies the connection profile’s config file, but is not taken into account immediately. So it’s useful only for the 2nd use of a given connection, that is mainly for users of NM persistence => not sure if it’s worth it.

#8 Updated by intrigeri 2016-01-14 14:34:34

  • Status changed from Confirmed to In Progress
  • Assignee changed from intrigeri to anonym
  • % Done changed from 0 to 10
  • QA Check set to Ready for QA
  • Feature Branch set to bugfix/10939-IPv6-log-spam

Please review’n’merge the topic branch, but this won’t be “fix committed” since it only fixes the problem for the default wired connection. That’s the best I can do for 2.0.

#9 Updated by anonym 2016-01-18 02:02:07

  • Subject changed from NetworkManager spams logs with IPv6 router solicitation failure to NetworkManager spams logs with IPv6 router solicitation failure for the default wired connection
  • % Done changed from 10 to 50

intrigeri wrote:
> Please review’n’merge the topic branch, but this won’t be “fix committed” since it only fixes the problem for the default wired connection. That’s the best I can do for 2.0.

IMHO this is good enough for even closing this ticket. I’m primarily interested in having a cleaner journal when testing stuff, and then I only ever use the default connection. I.e. I don’t care about a supposed full solution. So, let’s limit the scope of this ticket.

Feel free to open a new ticket for the full problem, if you feel it is important.

#10 Updated by anonym 2016-01-18 02:47:16

  • Status changed from In Progress to Fix committed
  • % Done changed from 50 to 100

Applied in changeset commit:7725759d89913f756de7e32fbdd1d3f22dd20f8f.

#11 Updated by anonym 2016-01-18 03:01:54

  • Assignee deleted (anonym)
  • QA Check changed from Ready for QA to Pass

#12 Updated by intrigeri 2016-01-18 10:55:27

> IMHO this is good enough for even closing this ticket. I’m primarily interested in having a cleaner journal when testing stuff, and then I only ever use the default connection. I.e. I don’t care about a supposed full solution. So, let’s limit the scope of this ticket.

FTR, this doesn’t address the “analyzing WhisperBack reports” use case, but whatever: we’ll open another ticket if it’s too painful (and perhaps I’ll just filter this out in tails-debugging-info, or something).

#13 Updated by anonym 2016-01-27 13:33:44

  • Status changed from Fix committed to Resolved