Comment # 11
on bug 993516
from Marius Tomaschewski
(In reply to Donald Curtis from comment #10)
> 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