http://bugzilla.suse.com/show_bug.cgi?id=993516
http://bugzilla.suse.com/show_bug.cgi?id=993516#c11
Marius Tomaschewski
Further investigation with this morning's boot: -------------------------------------------------------------------- Aug 18 08:52:10 eck001 kernel: r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded Aug 18 08:52:15 eck001 systemd[1]: Started wicked network management service daemon. Aug 18 08:52:15 eck001 systemd[1]: Started wicked network nanny service. Aug 18 08:52:16 eck001 kernel: r8169 0000:02:00.0 enp2s0: link down Aug 18 08:52:16 eck001 kernel: r8169 0000:02:00.0 enp2s0: link down Aug 18 08:52:16 eck001 kernel: IPv6: ADDRCONF(NETDEV_UP): enp2s0: link is not ready
this is from "ip link set up enp2s0", the kernel starts to detect carrier.
Aug 18 08:52:18 eck001 kernel: r8169 0000:02:00.0 enp2s0: link up
carrier detected.
Aug 18 08:52:18 eck001 kernel: IPv6: ADDRCONF(NETDEV_CHANGE): enp2s0: link becomes ready
the kernel assigns fe80:: address to the device marked it tentative (not yet usable) and starts preforms duplicate address detection (sends probe packet and waits 1sec for duplicate reports). once fe80:: is detected to be unique, the kernel joins multicast groups using it and sends out RS (RA request) to the IPv6 router, which responds with RA that contains info if to use dhcp6 and in which mode (managed address or info-only). Even wickedd-dhcp6 gets the request earlier, it waits until fe80:: address becomes ready (it is using it to send packages to dhcp server). Further, in DHCLIENT6_MODE=auto, it waits also for the router RA to provide the mode (managed or info) setting. wickedd* does not listen for the RA directly: to be consistent with the info kernel provides, it is using the kernel device flags and events emitted by the kernel when RA arrives and has been processed [when it does not forget it ... bug 972471 comment 65). Once the mode is given (by RA or setting), it starts sending dhcp6 packets as ipv6 multicasts from fe80::... to the ff02::1:2 all-dhcp-servers-and-relays address. (When the RA contains a /64 prefix with autonomous=true, kernel assigns an $prefix:$EUI64 (on ethernet, EUI64 is mac based suffix same to fe80::EUI64) and if privacy extensions are enabled, also $prefix:$random and preforms duplicate address detection for it/them same as for fe80 address. Further, the kernel also sets the ipv6 default route to the ipv6 router).
Aug 18 08:52:20 eck001 avahi-daemon[885]: New relevant interface enp2s0.IPv6 for mDNS. Aug 18 08:52:20 eck001 avahi-daemon[885]: Registering new address record for fe80::16da:e9ff:feec:a04d on enp2s0.*. Aug 18 08:52:22 eck001 wicked[959]: lo up Aug 18 08:52:22 eck001 wicked[959]: enp2s0 up
WAIT_FOR_INTERFACES alias "wicked ifup --timeout xxx eth0" is over and ifup reports. When there is dhcp4 _or_ dhcp6 lease (BOOTPROTO=dhcp case) it reports "up" for success. The other lease will arrive later and will be processed in background.
Aug 18 08:52:27 eck001 wickedd-dhcp6[953]: enp2s0: Accepting best DHCPv6 lease offer with weight 1 from server fe80::16da:e9ff:feec:a04d
wickedd-dhcp6 received a response from dhcp6 server and accepts (request or not rapid-commit)
Aug 18 08:52:27 eck001 wickedd-dhcp6[953]: enp2s0: Committed DHCPv6 lease
and commits it (=sends to wickedd to apply). wickedd is applying it and waiting until the address starts to be usable (non-tentative) and sends addrconf-up event ->nanny->ifup to continue and report lease as granted (if ifup is still waiting for it). In this case, the lease is applied after ifup returned already due to a short WAIT_FOR_INTERFACES.
-------------------------------------------------------------------- Time between the kernel loading the driver and link up/ready: 8 s. Time between the kernel loading the driver and systemd starting wicked: 5 s. Time between wicked being started and acknowledging the interface as being "up": 7 s. Time between wicked acknowledging that the interface as being "up" and the DHCPv6 lease being committed: 3 s.
1 secs is needed for duplicate address detection per address (fe80 + dhcp address -> 2sec) + time for RA and dhcp msg exchange and applying it.
-------------------------------------------------------------------- Given 8 s between the kernel loading the driver and acknowledging the link as being up/ready, the value of 8 s in config:WAIT_FOR_INTERFACES is possibly too tight -- I'll increase it to 10 s.
It depends on the driver nic how long the carrier detection/link up needs. It is basically the LOWER_UP flag visible in "ip a s". Except of this, some nics report carrier, but still need some time before they start to forward packets at all.
The values of dhcp:DHCLIENT_WAIT_AT_BOOT and dhcp:DHCLIENT6_WAIT_AT_BOOT could be increased to 5 s but, I can't see any reason to do so: - there seems to be only a requirement that WAIT_FOR_INTERFACES is at least double the value of the DHCP client "wait at boot" times.
Something like this, yes. WAIT_FOR_INTERFACES is how long "ifup" waits before it returns status. DHCLIENT*_WAIT_AT_BOOT how long we wait before we say "currently can't get a lease" aka defer and continue in background while it also causes ifup to stop waiting for the lease (inside of the timeout specified via WAIT_FOR_INTERFACES). We cannot change the defaults / timings by default, because they depend on the NIC hardware and also on the network, router, switch, ...
-------------------------------------------------------------------- One point that should maybe not be overlooked is that, the AVM FRITZ!Box 7490 DSL Router (and possibly other AVM models as well) seems to need the DHCP clients to sign off (release) before the DHCP client shuts down.
Well, we cannot change defaults without a feature request, so it has to remain as it is I fear. Documenting it somewhere would make sense.
-------------------------------------------------------------------- Does this "wicked tuning" procedure need to be documented?
This would be a good thing! There is a wicked portal at https://en.opensuse.org/Portal:Wicked and we could also add https://github.com/openSUSE/wicked/wiki and look how to sync them... See also https://github.com/openSUSE/wicked/blob/master/doc/FAQ.txt -- You are receiving this mail because: You are on the CC list for the bug.