Created attachment 987879 [details] radvdump output Description of problem: radvdump masks network to /64 when displaying Version-Release number of selected component (if applicable): radvd-1.12-2.fc21.i686 kernel-3.18.3-201.fc21.i686 How reproducible: always Steps to Reproduce: 1. Connect to network with >64 routes advertised 2. run wireshark to verify incoming RAs do indeed have /80 or whatever 3. run radvdump Actual results: radvdump it shows /80, but masks the address to 64 bits Expected results: radvdump shows the actual RA fields Additional info:
tcpdump of actual RA: 18:28:18.153891 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 32) fe80::20b:dbff:fe80:a9fa > fe80::21f:3cff:feb5:babf: [icmp6 sum ok] ICMP6, neighbor solicitation, length 32, who has fe80::21f:3cff:feb5:babf source link-address option (1), length 8 (1): 00:0b:db:80:a9:fa 18:28:18.156409 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 24) fe80::21f:3cff:feb5:babf > fe80::20b:dbff:fe80:a9fa: [icmp6 sum ok] ICMP6, neighbor advertisement, length 24, tgt is fe80::21f:3cff:feb5:babf, Flags [solicited] 18:28:20.915667 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 80) fe80::21a:a0ff:fe3a:a6ff > ff02::1: [icmp6 sum ok] ICMP6, router advertisement, length 80 hop limit 64, Flags [managed, other stateful], pref medium, router lifetime 30s, reachable time 0ms, retrans time 0ms prefix info option (3), length 32 (4): 2001:XXX:XXX:XXX::/64, Flags [onlink, auto], valid time 86400s, pref. time 14400s route info option (24), length 24 (3): 2001:XXX:XXX:XXX:11::/80, pref=high, lifetime=90s
Also, the kernel does not apply the route, even with: net.ipv6.conf.enp2s12.accept_dad = 1 net.ipv6.conf.enp2s12.accept_ra = 1 net.ipv6.conf.enp2s12.accept_ra_defrtr = 1 net.ipv6.conf.enp2s12.accept_ra_from_local = 0 net.ipv6.conf.enp2s12.accept_ra_pinfo = 0 net.ipv6.conf.enp2s12.accept_ra_rt_info_max_plen = 81 net.ipv6.conf.enp2s12.accept_ra_rtr_pref = 0 net.ipv6.conf.enp2s12.accept_redirects = 1 net.ipv6.conf.enp2s12.accept_source_route = 0 net.ipv6.conf.enp2s12.autoconf = 1
This used to work in F19 - except for NM mucking up settings periodically.
Allowing autoconf lets the kernel accept RAs - so that is just the twisty maze of IPv6 kernel options. However, even when the kernel accepts the /80 RA, radvdump display it incorrectly. So this is an radvdump problem.
radvdump should be fixed. NetworkManager doesn't allow the classic kernel autoconf to happen, which is good, as the kernel autoconf is terribly broken. NetworkManager and kernel issues are not related to the bug report on radvd package. Feel free to start new bug reports if needed and post a link to those. Do we have an /etc/radvd.conf to trigger the reported issue?
(In reply to Stuart D Gathman from comment #2) > net.ipv6.conf.enp2s12.accept_ra = 1 If you want to use kernel autoconfiguration unconditionally, accept_ra should be set to 2. When you set it to 1, you're triggering automatic behavior based on .forwarding. (In reply to Stuart D Gathman from comment #3) > This used to work in F19 - except for NM mucking up settings periodically. NetworkManager is responsible for handling IPv6 autoconfiguration as best as it can. Changing those sysctls when it's running is wrong with virtually all recent versions.
(In reply to Pavel Šimerda (pavlix) from comment #6) > (In reply to Stuart D Gathman from comment #2) > > net.ipv6.conf.enp2s12.accept_ra = 1 > > If you want to use kernel autoconfiguration unconditionally, accept_ra > should be set to 2. When you set it to 1, you're triggering automatic > behavior based on .forwarding. > > (In reply to Stuart D Gathman from comment #3) > > This used to work in F19 - except for NM mucking up settings periodically. > > NetworkManager is responsible for handling IPv6 autoconfiguration as best as > it can. Changing those sysctls when it's running is wrong with virtually all > recent versions. NetworkManager is disabled for these tests. I am aware that when using it, you have to go all in. I generally keep it disabled on desktops, which don't change their config often. The kernel autoconfiguration is confusing, but is working in this instance - which is a desktop with manual IPs.
(In reply to Pavel Šimerda (pavlix) from comment #5) > radvdump should be fixed. NetworkManager doesn't allow the classic kernel > autoconf to happen, which is good, as the kernel autoconf is terribly > broken. NetworkManager and kernel issues are not related to the bug report > on radvd package. Feel free to start new bug reports if needed and post a > link to those. > > Do we have an /etc/radvd.conf to trigger the reported issue? interface eth0 { AdvSendAdvert on; AdvManagedFlag on; AdvOtherConfigFlag on; MinRtrAdvInterval 3; MaxRtrAdvInterval 10; prefix 2001:XXXX:XXXX:XXXX::/64 { AdvOnLink on; AdvAutonomous on; AdvRouterAddr off; }; route 2001:XXXX:XXXX:XXXX:11::/80 { AdvRouteLifetime 90; AdvRoutePreference high; }; };
Confirmed also in Fedora 22 and Rawhide and thus in the latest upstream version. I consider it a minor issue as it only affects the radvd tool and can be worked around by using tcpdump instead which doesn't have this problem. Therefore moving to rawhide with the intention to fix it upstream.
Submitted upstream via GitHub: https://github.com/reubenhwk/radvd/pull/42