#20178: unstable ipv6 connectivity, odhcp6c invokes /lib/netifd/dhcpv6.script
too
often
--------------------------+----------------------------------
Reporter: simon.vetter | Owner: developers
Type: defect | Status: new
Priority: normal | Milestone: Chaos Calmer (trunk)
Component: base system | Version: Trunk
Keywords: |
--------------------------+----------------------------------
My ISP is currently multicasting RAs from 4 different source ip addresses:
{{{
07:07:24.803144 cc:4e:24:1c:14:00 > 33:33:00:00:00:01, ethertype IPv6
(0x86dd), length 118: (class 0xc0, hlim 255, next-header ICMPv6 (58)
payload length: 64) fe80::ce4e:24ff:fe1c:1400 > ff02::1: [icmp6 sum ok]
ICMP6, router advertisement, length 64
hop limit 64, Flags [none], pref medium, router lifetime 1800s,
reachable time 0s, retrans time 0s
source link-address option (1), length 8 (1): cc:4e:24:1c:14:00
mtu option (5), length 8 (1): 1500
prefix info option (3), length 32 (4): 2001:8e0:9ff:2000::/64,
Flags [onlink, auto], valid time 2592000s, pref. time 604800s
07:07:24.826919 cc:4e:24:1c:33:00 > 33:33:00:00:00:01, ethertype IPv6
(0x86dd), length 118: (class 0xc0, hlim 255, next-header ICMPv6 (58)
payload length: 64) fe80::ce4e:24ff:fe1c:3300 > ff02::1: [icmp6 sum ok]
ICMP6, router advertisement, length 64
hop limit 64, Flags [none], pref medium, router lifetime 1800s,
reachable time 0s, retrans time 0s
source link-address option (1), length 8 (1): cc:4e:24:1c:33:00
mtu option (5), length 8 (1): 1500
prefix info option (3), length 32 (4): 2001:8e0:9ff:2000::/64,
Flags [onlink, auto], valid time 2592000s, pref. time 604800s
07:07:24.827699 02:e0:52:00:25:01 > 33:33:00:00:00:01, ethertype IPv6
(0x86dd), length 118: (class 0xc0, hlim 255, next-header ICMPv6 (58)
payload length: 64) fe80:132::1 > ff02::1: [icmp6 sum ok] ICMP6, router
advertisement, length 64
hop limit 64, Flags [none], pref medium, router lifetime 1800s,
reachable time 0s, retrans time 0s
source link-address option (1), length 8 (1): 02:e0:52:00:25:01
mtu option (5), length 8 (1): 1500
prefix info option (3), length 32 (4): 2001:8e0:9ff:2000::/64,
Flags [onlink, auto], valid time 2592000s, pref. time 604800s
07:07:24.828420 02:e0:52:00:25:01 > 33:33:00:00:00:01, ethertype IPv6
(0x86dd), length 118: (class 0xc0, hlim 255, next-header ICMPv6 (58)
payload length: 64) 2001:8e0:9ff:2000::1 > ff02::1: [icmp6 sum ok] ICMP6,
router advertisement, length 64
hop limit 64, Flags [none], pref medium, router lifetime 1800s,
reachable time 0s, retrans time 0s
source link-address option (1), length 8 (1): 02:e0:52:00:25:01
mtu option (5), length 8 (1): 1500
prefix info option (3), length 32 (4): 2001:8e0:9ff:2000::/64,
Flags [onlink, auto], valid time 2592000s, pref. time 604800s
}}}
Although they are all advertising the same prefix and come in at roughly
the same time (usually within a few milliseconds every 30s), dhcp6c emits
multiple ra-updated events:
{{{
Sat Jul 25 07:25:39 2015 eth0.2 ra-updated
Sat Jul 25 07:25:39 2015 RA_REACHABLE=0
RA_ADDRESSES=2001:8e0:9ff:2000:xxxx:xxxx:xxxx:xxxx/64,604800,2592000
SERVER=2001:8e0:40:11::254 SHLVL=2 RA_MTU=1500
RA_ROUTES=::/0,fe80::ce4e:24ff:fe1c:3300,1767,512
2001:8e0:9ff:2000::/64,,2592000,256 ::/0,fe80:132::1,1767,512
::/0,fe80::ce4e:24ff:fe1c:1400,1800,512
PREFIXES=2001:8e0:xxxx:xxxx::/56,20
Sat Jul 25 07:25:39 2015 eth0.2 ra-updated
Sat Jul 25 07:25:39 2015 eth0.2 ra-updated
Sat Jul 25 07:25:40 2015 RA_REACHABLE=0
RA_ADDRESSES=2001:8e0:9ff:2000:xxxx:xxxx:xxxx:xxxx/64,604800,2592000
SERVER=2001:8e0:40:11::254 SHLVL=2 RA_MTU=1500
RA_ROUTES=::/0,fe80::ce4e:24ff:fe1c:3300,1800,512
2001:8e0:9ff:2000::/64,,2592000,256 ::/0,fe80:132::1,1767,512
::/0,fe80::ce4e:24ff:fe1c:1400,1800,512
PREFIXES=2001:8e0:xxxx:xxxx::/56,20
Sat Jul 25 07:25:40 2015 RA_REACHABLE=0
RA_ADDRESSES=2001:8e0:9ff:2000:xxxx:xxxx:xxxx:xxxx/64,604800,2592000
SERVER=2001:8e0:40:11::254 SHLVL=2 RA_MTU=1500
RA_ROUTES=::/0,fe80::ce4e:24ff:fe1c:3300,1800,512
2001:8e0:9ff:2000::/64,,2592000,256 ::/0,fe80:132::1,1800,512
::/0,fe80::ce4e:24ff:fe1c:1400,1800,512
PREFIXES=2001:8e0:xxxx:xxxx::/56,20
}}}
Additionally, all instances of the script seem to be fired concurrently,
potentially leading to race conditions.
On downstream interfaces where prefixes are delegated, this triggers
spurious RA transmissions:
{{{
23:37:39.859586 IP6 fe80::xxxx:xxxx:xxxx:xxxx > ff02::1: ICMP6, router
advertisement, length 120
23:37:39.860059 IP6 fe80::xxxx:xxxx:xxxx:xxxx > ff02::1: ICMP6, router
advertisement, length 120
23:37:39.860492 IP6 fe80::xxxx:xxxx:xxxx:xxxx > ff02::1: ICMP6, router
advertisement, length 120
23:37:41.088411 IP6 fe80::xxxx:xxxx:xxxx:xxxx > ff02::1: ICMP6, router
advertisement, length 120
23:38:11.808657 IP6 fe80::xxxx:xxxx:xxxx:xxxx > ff02::1: ICMP6, router
advertisement, length 120
23:38:11.809151 IP6 fe80::xxxx:xxxx:xxxx:xxxx > ff02::1: ICMP6, router
advertisement, length 120
23:38:12.115866 IP6 fe80::xxxx:xxxx:xxxx:xxxx > ff02::1: ICMP6, router
advertisement, length 120
23:38:13.037441 IP6 fe80::xxxx:xxxx:xxxx:xxxx > ff02::1: ICMP6, router
advertisement, length 120
23:38:44.986535 IP6 fe80::xxxx:xxxx:xxxx:xxxx > ff02::1: ICMP6, router
advertisement, length 120
23:38:44.986987 IP6 fe80::xxxx:xxxx:xxxx:xxxx > ff02::1: ICMP6, router
advertisement, length 120
23:38:44.987356 IP6 fe80::xxxx:xxxx:xxxx:xxxx > ff02::1: ICMP6, router
advertisement, length 120
23:38:45.908182 IP6 fe80::xxxx:xxxx:xxxx:xxxx > ff02::1: ICMP6, router
advertisement, length 120
23:39:20.314863 IP6 fe80::xxxx:xxxx:xxxx:xxxx > ff02::1: ICMP6, router
advertisement, length 120
23:39:20.315329 IP6 fe80::xxxx:xxxx:xxxx:xxxx > ff02::1: ICMP6, router
advertisement, length 120
23:39:20.622034 IP6 fe80::xxxx:xxxx:xxxx:xxxx > ff02::1: ICMP6, router
advertisement, length 120
23:39:21.333370 IP6 fe80::xxxx:xxxx:xxxx:xxxx > ff02::1: ICMP6, router
advertisement, length 120
}}}
See how every 30s, 4 RAs are emitted on the LAN side.
I've taken a deeper look at them, they all announce the same values
(prefix, link mtu, rdnss, route info) so they shouldn't be confusing any
on-link node, but frequent and spurious RAs are a known cause of battery
drain on mobile devices.
(Note that this one might be an odhcpd bug, but RA emission lines up with
script invocations).
More importantly, because /lib/netifd/dhcpv6.script refreshes route and
address lifetimes in the kernel's FIB, this causes routing instability,
interrupting traffic for about ~1s every 30-60s.
{{{
10:00:33.007279 IP6 2001:8e0:xxxx:xxxx::1 >
2001:8e0:xxxx:xxxx:94f0:8898:897f:117d: ICMP6, destination unreachable,
unreachable route 2001:6b0:e:2018::138, length 80
10:00:33.007782 IP6 2001:8e0:xxxx:xxxx::1 >
2001:8e0:xxxx:xxxx:94f0:8898:897f:117d: ICMP6, destination unreachable,
unreachable route 2001:6b0:e:2018::138, length 80
10:00:33.008197 IP6 2001:8e0:xxxx:xxxx::1 >
2001:8e0:xxxx:xxxx:94f0:8898:897f:117d: ICMP6, destination unreachable,
unreachable route 2001:6b0:e:2018::138, length 80
[...]
}}}
Here's my relevant /etc/config/network entry:
{{{
config interface 'wan6'
option ifname 'eth0.2'
option proto 'dhcpv6'
option reqaddress 'none' # don't request IA-NA
option noslaaconly '1' # don't configure addresses from ISP RA
pinfo (doesn't seem to work)
}}}
This is on a WDR3600 (env shows "board=TL-WDR4300") with Chaos Chalmer
rc3.
Let me know if you need additional info and sorry for the long post :)
--
Ticket URL: <https://dev.openwrt.org/ticket/20178>
OpenWrt <http://openwrt.org>
Opensource Wireless Router Technology
_______________________________________________
openwrt-tickets mailing list
[email protected]
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-tickets
