Bug 916956 - Acquiring of IPv6 address is delayed
Acquiring of IPv6 address is delayed
Status: RESOLVED FIXED
: 933590 (view as bug list)
Classification: openSUSE
Product: openSUSE Distribution
Classification: openSUSE
Component: Network
13.2
All openSUSE 13.2
: P5 - None : Minor (vote)
: ---
Assigned To: Marcus Meissner
E-mail List
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2015-02-09 16:17 UTC by Neil Rickert
Modified: 2017-01-19 14:19 UTC (History)
4 users (show)

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


Attachments
Dumps from wicked, as requested (35.83 KB, application/x-gzip)
2015-06-08 18:07 UTC, Neil Rickert
Details
Transcript (with "script" of "sysctl" command as requested in comment 8 (4.06 KB, text/plain)
2015-06-08 21:05 UTC, Neil Rickert
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Neil Rickert 2015-02-09 16:17:25 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
Comment 1 Marius Tomaschewski 2015-04-21 10:26:17 UTC
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?
Comment 2 Marius Tomaschewski 2015-04-21 10:28:51 UTC
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.
Comment 3 Neil Rickert 2015-04-21 19:27:25 UTC
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).
Comment 4 Neil Rickert 2015-04-23 14:59:16 UTC
>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.
Comment 5 Marius Tomaschewski 2015-06-08 12:43:50 UTC
(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
Comment 6 Neil Rickert 2015-06-08 18:07:36 UTC
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.
Comment 7 Marius Tomaschewski 2015-06-08 20:06:55 UTC
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.
Comment 8 Marius Tomaschewski 2015-06-08 20:30:09 UTC
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
Comment 9 Neil Rickert 2015-06-08 21:04:05 UTC
>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.
Comment 10 Neil Rickert 2015-06-08 21:05:55 UTC
Created attachment 637090 [details]
Transcript (with "script" of "sysctl" command as requested in comment 8
Comment 11 Neil Rickert 2015-06-08 21:10:37 UTC
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?
Comment 12 Marius Tomaschewski 2015-06-09 09:06:43 UTC
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.
Comment 13 Marius Tomaschewski 2015-12-01 11:35:53 UTC
*** Bug 933590 has been marked as a duplicate of this bug. ***
Comment 14 Marius Tomaschewski 2015-12-01 11:57:03 UTC
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).
Comment 15 Neil Rickert 2016-01-11 15:22:59 UTC
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.
Comment 16 Neil Rickert 2016-04-27 22:06:41 UTC
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.
Comment 17 Marcus Meissner 2017-01-19 14:19:46 UTC
if it happens again, please reopen :)