Bugzilla – Bug 916956
Acquiring of IPv6 address is delayed
Last modified: 2017-01-19 14:19:46 UTC
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:35.0) Gecko/20100101 Firefox/35.0 Build Identifier: When I boot my system, it does not have a public IPv6 address (it does have a link local address). The IPv6 address shows up later, usually within 15 minutes. It is possible that this is a router problem, though it doesn't look that way to me. If I use NetworkManager, I get an IPv6 address immediately. The problem only shows up with "wicked". Another system, running opensuse 13.1, shows the same problem when configured for "ifup" (but is fine with NetworkManager). If I run "systemctl restart network.service", I then get an IPv6 address. If I boot up a second system, whether using "wicked" or "NetworkManager", then the first system immediately gets an IPv6 address. Enabling DHCP6 does not affect anything (my router does not support DHCP6). My understanding is that the IPv6 address is generated from a route announcement. It looks to me as if the system does solicit such an announcement during startup, but it appears unready to accept that announcement. So starting a second system again solicits an announcement, and by this time the first system is now ready to respond to that announcement. Note that the problem is also present in Tumbleweed and in 13.1. Reproducible: Always
You could increase the RA Min/MaxRtrAdvInterval (e.g. 200/600) on the router sending RAs. It seems, that you have something that would send an RAs periodically, but does not answer router solicitations ... sounds like there would be a dnsmasq with --enable-ra option --> use radvd instead of this option. Except of fixing the router, you can override the network setup (=RA) using the DHCLIENT6_MODE=manage (or =info) either in /etc/sysconfig/network/ifcfg-$ifname file (per interface) or as global setting in the .../dhcp file to not wait for RAs, but immediately request an address. The RA defaults are initially (on "cold" interface, which was not yet up): AdvManagedFlag off [request dhcpv6 address + dns + ntp... or not] AdvOtherConfigFlag off [request dns + ntp... via dhcpv6 or not] Basically, when the interface goes UP (ip link set up dev eth0), the kernel assigns the fe80:$EUI64_from_MAC address and is verifying it for duplicates (basically a duplicate MAC check). Then the kernel sends out router solicitations for 60sec and awaits an RA from a router. When it receives any, it sets the managed/other config flags on the interface and sends them around via network, e.g. to wicked. Further, it sets the IPv6 default route through the router sending the RA [except the RA lifetime is 0] -- thus without RA, there will be no routing [DHCPv6 does not handle routes as DHCPv4 does]. When there is also a prefix X/Y {} block, the kernel checks it and when the prefix-length (Y) is 64 and the "AdvAutonomous on" is set -- when yes, it will assign a (SLAAC - Stateless Addresses) from this prefix, but this does not have anything to do with DHCPv6. wickedd-dhcp6 starts in DHCLIENT6_MODE=auto by default and waits until a) fe80 address is set and verified on the interface [it is using it to send/receive dhcp messages] and b) the kernel reports that the interface is managed=on to request an address or other-config=on to request additional dns,ntp info only. before it starts DHCPv6 processing. Further, "ip link set down" does not resets the RA flags on the interface. Once the kernel received an RA once, it will continue to use the managed and other-config settings it found in the last RA. Thus once it received RA, "rcnetwork restart" or similar, will request the DHCPv6 address immediately. I think, this provides you the solution: either fix the router or override it by DHCLIENT6_MODE=managed. Does it work for you?
BTW: You can set the setting also at install time using: ifcfg=*=dhcp,DHCLIENT6_MODE=managed See https://en.opensuse.org/SDB:Linuxrc for more tweaks.
Thanks. I've changed from "auto" to "managed" in the "dhcp" file. I'll see how it goes over the next few boots, and then respond to the "needinfo". My router is provided by the ISP and has very little configurability for IPv6 (other than enable/disable).
>I think, this provides you the solution: either fix the router or override >it by DHCLIENT6_MODE=managed. Does it work for you? After several reboots, I'm afraid that the change from "auto" to "managed" has not helped at all.
(In reply to Neil Rickert from comment #4) > >I think, this provides you the solution: either fix the router or override > >it by DHCLIENT6_MODE=managed. Does it work for you? > > After several reboots, I'm afraid that the change from "auto" to "managed" > has not helped at all. What did you changed and where? Unfortunately, this report does not contain any valuable informations. Neither config nor debug logs, so I cannot say much more about it than in the comments before. Please install the "radvd" package. Enable debug by editing the variables in /etc/sysconfig/network/config file: WICKED_DEBUG="all" WICKED_LOG_LEVEL="debug" Then move the /etc/sysconfig/network/ifcfg-$ifname file away from the directory or rename to e.g. .ifcfg-$ifname, so there is no attempt to set up it at boot time at all. Then please reboot and login twice / open two root terminals. Move the file back to it's place. In the first root console/terminal window start: radvdump | logger -t radvdump 2>&1 in the 2nd, start: "wicked ifup all" (or just "ip link set up $ifname"). Wait until the command finished and "ip -6 r s" starts to show a default route and/or routes with a global scope IPv6 network. You can abort the radvdump running in the other console with Ctrl-C now. Finally, collect the logs: wicked show-config > config-dump.log wicked show-xml > status-dump.log journalctl -b -o short-precise > journal.log review the files and XXX-out/anonymize anything you consider secret in them and create an archive of it: tar -czf bug916956-logs.tgz config-dump.log status-dump.log journal.log Please attach the archive to this bug report (as private comment), then we may be able to see more. See also: https://en.opensuse.org/openSUSE:Bugreport_wicked
Created attachment 637070 [details] Dumps from wicked, as requested Note 1: When I installed "radvd", that also pulled in "libdvdcss2". This seems inappropriate, though not a serious concern here. Note 2: After running "wicked ifup all" a global IPv6 was immediately available without a delay. So these logs might not show anything useful. I repeated the test, and again the global IPv6 address was immediately available. The attachment is for the first trial. Note 3: I couldn't see how to make the attachment private, though perhaps I misunderstood something in your comment. I'm not too worried about revealing the IPv6 address, so no serious concern. Note 4: for the record, after reboot I logged into Icewm, and opened root terminals there.
Your router does not enable DHCPv6: Jun 08 12:12:57.073213 nwr8 radvdump[2239]: AdvManagedFlag off; Jun 08 12:12:57.073981 nwr8 radvdump[2239]: AdvOtherConfigFlag off; The RA has a lifetime, that is default route should be set: Jun 08 12:12:57.075524 nwr8 radvdump[2239]: AdvDefaultLifetime 1800; and it provides autoconf prefix/64: Jun 08 12:12:57.079668 nwr8 radvdump[2239]: AdvAutonomous on; so ipv6 autoconf addrs and default route should be fine so far, except something has been tweaked (-> sysctl net.ipv6.conf.eno1) ... The rest is done by the kernel, nothing to do here for wicked.
BTW: Please "systemctl disable SuSEfirewall2 SuSEfirewall2_init" + reboot. Not that it simply blocks RAs. And please attach the output of: sysctl net.ipv6.conf.eno1 net.ipv6.conf.all net.ipv6.conf.default
>Your router does not enable DHCPv6: Yes, I mentioned that in the initial report. >something has been tweaked (-> sysctl net.ipv6.conf.eno1) ... That isn't anything that I did (as far as I know). After disabling the firewall, with the suggested command, the system came up with IPv6 global addresses. But I'll need to repeat that to be sure, because occasionally there isn't a delay. I'll attach the output from the "sysctl" command.
Created attachment 637090 [details] Transcript (with "script" of "sysctl" command as requested in comment 8
After an additional reboot, it again acquired IPv6 global addresses with no evident delay. Does that suggest that there's a problem in the firewall rules?
The problem is the time between SuSEfirewall2_init and SuSEfirewall2. SuSEfirewall2_init does not permit the RAs (ipv6-icmptype 134).... # systemctl start SuSEfirewall2_init # ip6tables -L -nv Chain INPUT (policy DROP 3 packets, 200 bytes) pkts bytes target prot opt in out source destination 0 0 ACCEPT all lo * ::/0 ::/0 0 0 ACCEPT all * * ::/0 ::/0 ctstate ESTABLISHED 0 0 ACCEPT icmpv6 * * ::/0 ::/0 ctstate RELATED 0 0 ACCEPT udp * * ::/0 ::/0 udp dpt:546 Chain FORWARD (policy DROP 0 packets, 0 bytes) pkts bytes target prot opt in out source destination Chain OUTPUT (policy ACCEPT 2 packets, 144 bytes) pkts bytes target prot opt in out source destination 0 0 ACCEPT all * lo ::/0 ::/0 Chain reject_func (0 references) pkts bytes target prot opt in out source destination 0 0 REJECT tcp * * ::/0 ::/0 reject-with tcp-reset 0 0 REJECT udp * * ::/0 ::/0 reject-with icmp6-port-unreachable 0 0 REJECT all * * ::/0 ::/0 reject-with icmp6-addr-unreachable 0 0 DROP all * * ::/0 ::/0 # systemctl start SuSEfirewall2 # ip6tables -L input_ext -nv Chain input_ext (1 references) pkts bytes target prot opt in out source destination 0 0 ACCEPT icmpv6 * * ::/0 ::/0 ipv6-icmptype 128 0 0 ACCEPT icmpv6 * * ::/0 ::/0 ipv6-icmptype 133 0 0 ACCEPT icmpv6 * * ::/0 ::/0 ipv6-icmptype 134 0 0 ACCEPT icmpv6 * * ::/0 ::/0 ipv6-icmptype 135 0 0 ACCEPT icmpv6 * * ::/0 ::/0 ipv6-icmptype 136 0 0 ACCEPT icmpv6 * * ::/0 ::/0 ipv6-icmptype 137 0 0 ACCEPT icmpv6 * * ::/0 ::/0 ipv6-icmptype 130 0 0 LOG tcp * * ::/0 ::/0 limit: avg 3/min burst 5 tcp dpt:22 flags:0x17/0x02 LOG flags 6 level 4 prefix "SFW2-INext-ACC-TCP " 0 0 ACCEPT tcp * * ::/0 ::/0 tcp dpt:22 0 0 LOG tcp * * ::/0 ::/0 limit: avg 3/min burst 5 tcp flags:0x17/0x02 LOG flags 6 level 4 prefix "SFW2-INext-DROP-DEFLT " 0 0 LOG icmpv6 * * ::/0 ::/0 limit: avg 3/min burst 5 LOG flags 6 level 4 prefix "SFW2-INext-DROP-DEFLT " 0 0 LOG udp * * ::/0 ::/0 limit: avg 3/min burst 5 ctstate NEW LOG flags 6 level 4 prefix "SFW2-INext-DROP-DEFLT " 0 0 DROP all * * ::/0 ::/0 Marcus, idea how we can fix this? I'd permit icmpv6 in "init" state.
*** Bug 933590 has been marked as a duplicate of this bug. ***
Workaround to not break IPv6 RA, ... is setting: FW_BOOT_FULL_INIT="yes" in /etc/sysconfig/SuSEfirewall2 (at least in SuSEfirewall2-3.6.312-3.3.noarch on leap-41.1).
Reply to comment #14 >Workaround to not break IPv6 RA, ... is setting: > > FW_BOOT_FULL_INIT="yes" This causes problems for me on my main desktop. I'm using it elsewhere, but not on my main desktop (using Leap 42.1). The problem is that the system is an NFS server. And when I use that setting, sometimes it comes up with the firewall blocking NFS. It's probably a timing issue. Apparently, NFS needs to be started before the firewall.
It looks to me as if this has been fixed. Or, at least, I am no longer seeing the problem. This dates from a "wicked" update in March. Since that time, I have had IPv6 addresses at boot, at least on 42.1. Checking 13.2 and 13.1, I also seem to no longer have the problem there. I think they had wicked updates at around the same time. There has been another "wicked" update since then, and it is still working correctly. On the first boot after the March "wicked" update, I did have and NFS problem. I had to restart the firewall on my NFS server. But that has not recurred since. So it all seems to be working as far as I can tell.
if it happens again, please reopen :)