Bug 933590 - wicked: IPv6 public routes show up after approximately 9 minutes
wicked: IPv6 public routes show up after approximately 9 minutes
Status: RESOLVED DUPLICATE of bug 916956
Classification: openSUSE
Product: openSUSE Distribution
Classification: openSUSE
Component: Network
Leap 42.1
All openSUSE 42.1
: P5 - None : Major (vote)
: Leap 42.1
Assigned To: wicked maintainers
E-mail List
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2015-06-04 08:55 UTC by Lars Müller
Modified: 2015-12-01 12:26 UTC (History)
6 users (show)

See Also:
Found By: Development
Services Priority:
Business Priority:
Blocker: No
Marketing QA Status: ---
IT Deployment: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Lars Müller 2015-06-04 08:55:34 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
Comment 1 Neil Rickert 2015-06-04 16:10:25 UTC
See also bug 916956
Comment 2 Lars Müller 2015-06-04 16:37:48 UTC
(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.
Comment 3 Neil Rickert 2015-06-05 03:04:06 UTC
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
Comment 4 Marius Tomaschewski 2015-06-08 12:03:19 UTC
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.
Comment 5 Marius Tomaschewski 2015-06-08 12:45:45 UTC
See also https://bugzilla.opensuse.org/show_bug.cgi?id=916956#c5 how to
catch such RA processing conditions.
Comment 6 Marius Tomaschewski 2015-06-08 20:17:30 UTC
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/
Comment 7 Marius Tomaschewski 2015-06-09 09:37:34 UTC
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.
Comment 8 Pawel Wieczorkiewicz 2015-06-17 10:08:06 UTC
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.
Comment 9 Pawel Wieczorkiewicz 2015-06-30 15:04:38 UTC
Fixed in master. To be released with wicked 0.6.19.
Comment 10 Ruediger Meier 2015-11-27 11:47:53 UTC
I have this issue on a fresh installed openSUSE Leap. Default Network setup.
My OpenWrt router runs dhcpv6 as well as IPv6 auto config.
Comment 11 Marius Tomaschewski 2015-12-01 11:35:52 UTC
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 12 Ruediger Meier 2015-12-01 11:58:16 UTC
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.
Comment 13 Marius Tomaschewski 2015-12-01 12:26:01 UTC
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.