Bugzilla – Bug 933590
wicked: IPv6 public routes show up after approximately 9 minutes
Last modified: 2015-12-01 12:26:01 UTC
The network device is configured as a bridge. hip:~ # cat /etc/sysconfig/network/ifcfg-br0 BOOTPROTO='dhcp' BRIDGE='yes' BRIDGE_FORWARDDELAY='0' BRIDGE_PORTS='eno1' BRIDGE_STP='off' BROADCAST='' DHCLIENT_SET_DEFAULT_ROUTE='yes' ETHTOOL_OPTIONS='' IPADDR='' MTU='' NETMASK='' NETWORK='' REMOTE_IPADDR='' STARTMODE='auto' lmuelle@hip:~> ip -6 r s fe80::/64 dev br0 proto kernel metric 256 lmuelle@hip:~> uptime 10:44 0:08 an, 8 Benutzer, Durchschnittslast: 0,00, 0,20, 0,19 and some minutes later I see: lmuelle@hip:~> ip -6 r s 2a02:3100:9e02:d200::/64 dev br0 proto kernel metric 256 expires 6060sec mtu 1492 2a02:3100:9e04:1e00::/64 dev br0 proto kernel metric 256 expires 7124sec mtu 1492 fd00::/64 dev br0 proto kernel metric 256 expires 7124sec mtu 1492 fe80::/64 dev br0 proto kernel metric 256 mtu 1492 default via fe80::2665:11ff:fef7:203b dev br0 proto ra metric 1024 expires 1724sec mtu 1492 hoplimit 255 lmuelle@hip:~> uptime 10:47 0:11 an, 9 Benutzer, Durchschnittslast: 0,77, 0,51, 0,31
See also bug 916956
(In reply to Neil Rickert from comment #1) > See also bug 916956 Thanks. This is very likely a duplicate of bug 916956 But I'd like one of our wicked maintainers to decide on this as the delay I see is a bit smaller. The Internet Access Device (IAD) I'm using is from from the vendor AVM, the model has the name Fritzbox, and model number 7390. The most current firmwawre version 06.23 is installed.
For me, the amount of time it takes varies. I perhaps should have mentioned that my router is a 2Wire 3800HGV-B, with firmware version 6.11.1.29-plus.tm
This is not a wicked bug. For IPv6, routes are handled completely by the kernel [or statically via config], DHCPv6 is not involved here at all. When the interface goes up (e.g. "ip link set up eth0") the kernel assigns a link address to the interface (fe80::.../64), which is usually derived from the mac address. Then it verifies it for duplicates on the network and when there is no duplicate, it sends out a RS (router solicitation) asking for RA (router advertisement) for 60 seconds. When the router sends one back and the lifetime is not 0, the kernel will set a default route via this router. When the router answer periodically only [every 9 minutes], and ignores RS ... well, there will be no default route until RA arrives.
See also https://bugzilla.opensuse.org/show_bug.cgi?id=916956#c5 how to catch such RA processing conditions.
For DHCP use cases, I've added a workaround to catch a condition where the kernel forgets to send NEWLINK events when the timers are 0 (means unspecified / no change to before), even the RA flags change. [I've prepared my old FRITZ!Box Fon WLAN 7270 v2 / FRITZ!OS 06.05 in a test network]: Mon Jun 8 22:03:05 CEST 2015: AdvReachableTime 0; Mon Jun 8 22:03:05 CEST 2015: AdvRetransTimer 0; https://github.com/mtomaschewski/wicked/tree/no-newlink6-workaround Can you install RPMs from here and test if this workaround works: http://download.opensuse.org/repositories/home:/mtomaschewski:/wicked/
OK, I've opened a kernel bug for the IPv6 RA flags (managed/other-config) changes and omitted NEWLINK when AdvReachableTime==AdvRetransTimer==0 the above patch is trying to workaround: https://bugzilla.suse.com/show_bug.cgi?id=934067 See also bug 916956 comment 12 -- it is SUSEfirewall2_init which does not permit ICMPv6 (RAs, ...) -- unlike SuSEfirewall2, which is setting rules allowing it. Lars, could you test if this works properly when SUSEfirewall2* is disabled? Then we can in fact resolve this bug as duplicate of bug 916956.
Please see comment#6 and comment#7. The patch mentioned there is already merged to master, and can be tested using wicked from OBS network:wicked:master repo.
Fixed in master. To be released with wicked 0.6.19.
I have this issue on a fresh installed openSUSE Leap. Default Network setup. My OpenWrt router runs dhcpv6 as well as IPv6 auto config.
DHCPv6 does not deal with routes at all -- this is done in the kernel (not in wicked) using the IPv6 RA sent by the router -> blocked by SUSEfierwall2. The delayed DHCPv6 address requests issues are fixed in the kernel (patches accepted upstream) and a workaround trying to catch it is also in wicked. See also comment 7. *** This bug has been marked as a duplicate of bug 916956 ***
comment 7 contains a link to a non-public bug ... The other SuSEfirewall2 bugs are ignored since six months. IMO it's a real show stopper that Leap boots up without IPv6.
Yes, bug 934067 is the SLES-12 bug report I've opened to fix the kernel to emit NEWLINK events when "Reachable Time" and "Retrans Timer" are 0 in RA: "A value of zero means unspecified (by this router)", and "In such cases, the parameter should be ignored and the host should continue using whatever value it is already using" as stated in rfc4861 4.2/6.3.4, that is not a reason to skip anything, just nothing special provided/enforced by the router as briefly also described in comment 7. Not emitting them caused, that DHCPv6 started to request address/info late and does not has anything to do with the routes, which were set -- except, SUSEfirewall2 blocks the RA (in it's init phase). Sorry, better would be to link the info here. The kernel patches are here: http://patchwork.ozlabs.org/patch/512486/ http://patchwork.ozlabs.org/patch/512646/ and accepted upstream. Workaround to not break IPv6 RA, ... is setting: FW_BOOT_FULL_INIT="yes" in /etc/sysconfig/SuSEfirewall2.