NetworkManager does not disable accept_ra when a managed device is set to ipv6 method=ignore

Bug #1704210 reported by Mathieu Trudel-Lapierre
10
This bug affects 2 people
Affects Status Importance Assigned to Milestone
network-manager (Ubuntu)
Confirmed
Undecided
Unassigned

Bug Description

As per the title; it looks (at first glance anyway, running TestNetworkManager.test_eth_dhcp6_off integration test from nplan) like NM does not set accept_ra to false, or provide a method for specifying whether you want to accept IPv6 RAs on that device. When IPv6 is disabled, we might also not want the kernel to heed RAs and create SLAAC addresses.

NM already is able to disable accept_ra, since it does so when a device transitions to UNAVAILABLE or DISCONNECTED in some cases (see src/devices/nm-device.c).

Revision history for this message
Mathieu Trudel-Lapierre (cyphermox) wrote :

ubuntu@autopkgtest:/tmp/autopkgtest.BeZID5/build.9bb/real-tree$ sudo python3 tests/integration.py TestNetworkManager.test_eth_dhcp6_off
test_eth_dhcp6_off (__main__.TestNetworkManager) ... FAIL

======================================================================
FAIL: test_eth_dhcp6_off (__main__.TestNetworkManager)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "tests/integration.py", line 1618, in test_eth_dhcp6_off
    self.assert_iface_up(self.dev_e_client, [], ['inet6 2600:'])
  File "tests/integration.py", line 313, in assert_iface_up
    self.assertNotRegex(out, r, out)
AssertionError: Regex matched: 'inet6 2600:' matches 'inet6 2600:' in '650: eth42@veth42: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000\n link/ether f6:be:d6:b1:7e:b0 brd ff:ff:ff:ff:ff:ff\n inet 192.168.1.100/24 brd 192.168.1.255 scope global eth42\n valid_lft forever preferred_lft forever\n inet6 2600::f4be:d6ff:feb1:7eb0/64 scope global mngtmpaddr dynamic \n valid_lft 3597sec preferred_lft 3597sec\n inet6 fe80::f4be:d6ff:feb1:7eb0/64 scope link \n valid_lft forever preferred_lft forever\n' : 650: eth42@veth42: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether f6:be:d6:b1:7e:b0 brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.100/24 brd 192.168.1.255 scope global eth42
       valid_lft forever preferred_lft forever
    inet6 2600::f4be:d6ff:feb1:7eb0/64 scope global mngtmpaddr dynamic
       valid_lft 3597sec preferred_lft 3597sec
    inet6 fe80::f4be:d6ff:feb1:7eb0/64 scope link
       valid_lft forever preferred_lft forever

----------------------------------------------------------------------
Ran 1 test in 7.976s

FAILED (failures=1)

Revision history for this message
Mathieu Trudel-Lapierre (cyphermox) wrote :

ubuntu@autopkgtest:~$ sysctl -a | grep veth | grep accept
sysctl: permission denied on key 'fs.protected_hardlinks'
sysctl: permission denied on key 'fs.protected_symlinks'
sysctl: permission denied on key 'kernel.cad_pid'
sysctl: permission denied on key 'kernel.unprivileged_userns_apparmor_policy'
sysctl: permission denied on key 'kernel.usermodehelper.bset'
sysctl: permission denied on key 'kernel.usermodehelper.inheritable'
sysctl: permission denied on key 'net.core.bpf_jit_harden'
sysctl: permission denied on key 'net.core.bpf_jit_kallsyms'
sysctl: permission denied on key 'net.ipv4.tcp_fastopen_key'
sysctl: permission denied on key 'net.ipv6.conf.all.stable_secret'
sysctl: permission denied on key 'net.ipv6.conf.default.stable_secret'
sysctl: permission denied on key 'net.ipv6.conf.ens3.stable_secret'
sysctl: permission denied on key 'net.ipv6.conf.eth42.stable_secret'
sysctl: permission denied on key 'net.ipv6.conf.eth43.stable_secret'
sysctl: permission denied on key 'net.ipv6.conf.hwsim0.stable_secret'
sysctl: permission denied on key 'net.ipv6.conf.lo.stable_secret'
net.ipv4.conf.veth42.accept_local = 0
net.ipv4.conf.veth42.accept_redirects = 1
net.ipv4.conf.veth42.accept_source_route = 1
net.ipv4.conf.veth42.arp_accept = 0
net.ipv4.conf.veth43.accept_local = 0
net.ipv4.conf.veth43.accept_redirects = 1
net.ipv4.conf.veth43.accept_source_route = 1
net.ipv4.conf.veth43.arp_accept = 0
net.ipv6.conf.veth42.accept_dad = 1
net.ipv6.conf.veth42.accept_ra = 1
net.ipv6.conf.veth42.accept_ra_defrtr = 1
net.ipv6.conf.veth42.accept_ra_from_local = 0
net.ipv6.conf.veth42.accept_ra_min_hop_limit = 1
net.ipv6.conf.veth42.accept_ra_mtu = 1
net.ipv6.conf.veth42.accept_ra_pinfo = 1
net.ipv6.conf.veth42.accept_ra_rt_info_max_plen = 0
sysctl: permission denied on key 'net.ipv6.conf.veth42.stable_secret'
sysctl: permission denied on key 'net.ipv6.conf.veth43.stable_secret'
sysctl: permission denied on key 'net.ipv6.conf.wlan0.stable_secret'
sysctl: permission denied on key 'net.ipv6.conf.wlan1.stable_secret'
net.ipv6.conf.veth42.accept_ra_rtr_pref = 1
net.ipv6.conf.veth42.accept_redirects = 1
net.ipv6.conf.veth42.accept_source_route = 0
net.ipv6.conf.veth43.accept_dad = 1
net.ipv6.conf.veth43.accept_ra = 1
net.ipv6.conf.veth43.accept_ra_defrtr = 1
net.ipv6.conf.veth43.accept_ra_from_local = 0
net.ipv6.conf.veth43.accept_ra_min_hop_limit = 1
net.ipv6.conf.veth43.accept_ra_mtu = 1
net.ipv6.conf.veth43.accept_ra_pinfo = 1
net.ipv6.conf.veth43.accept_ra_rt_info_max_plen = 0
net.ipv6.conf.veth43.accept_ra_rtr_pref = 1
net.ipv6.conf.veth43.accept_redirects = 1
net.ipv6.conf.veth43.accept_source_route = 0
sysctl: permission denied on key 'vm.mmap_rnd_bits'
sysctl: permission denied on key 'vm.mmap_rnd_compat_bits'
sysctl: permission denied on key 'vm.stat_refresh'

Revision history for this message
Mathieu Trudel-Lapierre (cyphermox) wrote :

ubuntu@autopkgtest:~$ sudo cat /run/NetworkManager/system-connections/netplan-eth42
[connection]
id=netplan-eth42
type=ethernet
interface-name=eth42

[ethernet]
wake-on-lan=0

[ipv4]
method=manual
address1=192.168.1.100/24

[ipv6]
method=ignore
ubuntu@autopkgtest:~$ sudo cat /run/NetworkManager/system-connections/netplan-eth43
[connection]
id=netplan-eth43
type=ethernet
interface-name=eth43

[ethernet]
wake-on-lan=0

[ipv4]
method=link-local

[ipv6]
method=ignore

Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in network-manager (Ubuntu):
status: New → Confirmed
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.