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
lmuelle@hip:~> ip -6 r s
fe80::/64 dev br0 proto kernel metric 256
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
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
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 18.104.22.168-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;
Can you install RPMs from here and test if this workaround works:
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:
See also bug 916956 comment 12 -- it is SUSEfirewall2_init which does not
permit ICMPv6 (RAs, ...) -- unlike SuSEfirewall2, which is setting rules
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:
and accepted upstream.
Workaround to not break IPv6 RA, ... is setting: