Modify

Opened 3 years ago

Last modified 2 years ago

#20178 assigned defect

unstable ipv6 connectivity, odhcp6c invokes /lib/netifd/dhcpv6.script too often

Reported by: simon.vetter Owned by: cyrus
Priority: normal Milestone: Chaos Calmer 15.05
Component: base system Version: Trunk
Keywords: Cc:

Description

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 :)

Attachments (0)

Change History (5)

comment:1 Changed 3 years ago by cyrus

  • Owner changed from developers to cyrus
  • Status changed from new to assigned

comment:2 Changed 2 years ago by simon.vetter

This still happens with the latest release, Chaos Calmer 15.05.

comment:3 Changed 2 years ago by barbaracus@…

revisiting this issue I wonder if this patch [1] from D. Taht is enough to get reliable IPv6 connectivity.

[1] https://github.com/dtaht/odhcp6c/commit/5dc1d802efb6b6b221e452e1eb3547dab5afda75

comment:4 Changed 2 years ago by anonymous

Is there a way to have a reliable IPv6 connectivity with openWRT?

Since odhcp6c doesn't work as expected, is there any other dhcp6 client working with the openwrt configuration system that supports prefix delegation?

It seems odd to me that this major issue isn't going anywhere, given the shortage of IPv4 addresses and the increasing IPv6 relevance.

comment:5 Changed 2 years ago by jow

No there is no real replacement for it. Did you try the changes suggested in comment:3? If you find them to be helpful I'll try to upstream them.

Add Comment

Modify Ticket

Action
as assigned .
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.