It seems that the current dhcpcd module (/lib64/netifrc/net/dhcpcd.sh) has a timing race condition concerning the start of dhcpcd and the subsequent router soliciation message sent. In the failure case you see the following happening when the interface gets started: dhcpcd[26156]: wlan0: sending Router Solicitation dhcpcd[26156]: wlan0: ipv6nd_sendrsprobe: sendmsg: Cannot assign requested address A simple workaround for the problem is a simple "sleep 2" in /lib64/netifrc/net/dhcpcd.sh just before starting dhcpcd. I assume the link local address used to send the router soliciation message (fe80::) is not yet ready when dhcpcd starts without delay and so the first packet sent to this address fails to be received by the router. This in turn results in _no_ IPv6 address configured on the interface until the next RA gets received, which can take up to 5min in default radvd's configuration. Adding the above workaround results in receiving the IPv6 address faster than the IPv4, even through we wait for 2 seconds (after being backgrounded). I'm no IPv6 expert (yet) so I can not say if this is dhcpcd's fault or netifrc's. But I think it's important to fix this. Having reliable dynamic addresses is important for many folks I would think. Reproducible: Always Steps to Reproduce: 1. configure dhcpcd and IPv6 for an interface config_wlan0="dhcp" wpa_supplicant_wlan0="-dd -f /var/log/wpa_supplicant.log" modules_wlan0="dhcpcd" dhcpcd_wlan0="-d" 2. start the interface /etc/init.d/net.wlan0 start 3. check syslog Actual Results: Dec 10 18:27:29 pixel1-wlan0 dhcpcd[26156]: wlan0: soliciting an IPv6 router Dec 10 18:27:29 pixel1-wlan0 dhcpcd[26156]: wlan0: sending Router Solicitation Dec 10 18:27:29 pixel1-wlan0 dhcpcd[26156]: wlan0: ipv6nd_sendrsprobe: sendmsg: Cannot assign requested address FAIL -------------------------------------------------^ Dec 10 18:27:29 pixel1-wlan0 dhcpcd[26156]: wlan0: using ClientID ff:00:00:00:02:00:01:00:01:1a:39:27:77:9c:2a:70:66:8a:61 Dec 10 18:27:29 pixel1-wlan0 dhcpcd[26156]: wlan0: reading lease `/var/lib/dhcpcd/dhcpcd-wlan0.lease' Dec 10 18:27:29 pixel1-wlan0 dhcpcd[26156]: wlan0: rebinding lease of 172.16.24.32 Dec 10 18:27:29 pixel1-wlan0 dhcpcd[26156]: wlan0: sending REQUEST (xid 0x66ddf6a9), next in 3.96 seconds Dec 10 18:27:29 pixel1-wlan0 dhcpcd[26156]: wlan0: acknowledged 172.16.24.32 from 172.16.24.1 Dec 10 18:27:29 pixel1-wlan0 dhcpcd[26156]: wlan0: checking for 172.16.24.32 Dec 10 18:27:29 pixel1-wlan0 dhcpcd[26156]: wlan0: sending ARP probe (1 of 3), next in 1.99 seconds Dec 10 18:27:31 pixel1-wlan0 dhcpcd[26156]: wlan0: sending ARP probe (2 of 3), next in 1.74 seconds Dec 10 18:27:33 pixel1-wlan0 dhcpcd[26156]: wlan0: sending ARP probe (3 of 3), next in 2.00 seconds Dec 10 18:27:35 pixel1-wlan0 dhcpcd[26156]: wlan0: leased 172.16.24.32 for 43200 seconds Dec 10 18:27:35 pixel1-wlan0 dhcpcd[26156]: wlan0: renew in 21600 seconds, rebind in 37800 seconds Dec 10 18:27:35 pixel1-wlan0 dhcpcd[26156]: wlan0: adding IP address 172.16.24.32/24 Dec 10 18:27:35 pixel1-wlan0 dhcpcd[26156]: wlan0: adding host route to 172.16.24.32 via 127.0.0.1 Dec 10 18:27:35 pixel1-wlan0 dhcpcd[26156]: wlan0: adding route to 172.16.24.0/24 Dec 10 18:27:35 pixel1-wlan0 dhcpcd[26156]: wlan0: adding default route via 172.16.24.1 Dec 10 18:27:35 pixel1-wlan0 dhcpcd[26156]: wlan0: writing lease `/var/lib/dhcpcd/dhcpcd-wlan0.lease' Dec 10 18:27:35 pixel1-wlan0 dhcpcd[26156]: wlan0: executing `/lib/dhcpcd/dhcpcd-run-hooks' BOUND Expected Results: Dec 10 17:44:32 pixel1-wlan0 dhcpcd[16183]: wlan0: sending Router Solicitation Dec 10 17:44:32 pixel1-wlan0 dhcpcd[16183]: wlan0: using ClientID ff:00:00:00:02:00:01:00:01:1a:39:27:77:9c:2a:70:66:8a:61 Dec 10 17:44:32 pixel1-wlan0 dhcpcd[16183]: wlan0: reading lease `/var/lib/dhcpcd/dhcpcd-wlan0.lease' Dec 10 17:44:32 pixel1-wlan0 dhcpcd[16183]: wlan0: rebinding lease of 172.16.24.32 Dec 10 17:44:32 pixel1-wlan0 dhcpcd[16183]: wlan0: sending REQUEST (xid 0x11339470), next in 3.02 seconds Dec 10 17:44:32 pixel1-wlan0 dhcpcd[16183]: wlan0: acknowledged 172.16.24.32 from 172.16.24.1 Dec 10 17:44:32 pixel1-wlan0 dhcpcd[16183]: wlan0: checking for 172.16.24.32 Dec 10 17:44:32 pixel1-wlan0 dhcpcd[16183]: wlan0: sending ARP probe (1 of 3), next in 1.96 seconds Dec 10 17:44:34 pixel1-wlan0 dhcpcd[16183]: wlan0: sending ARP probe (2 of 3), next in 1.89 seconds Dec 10 17:44:35 pixel1-wlan0 dhcpcd[16183]: wlan0: Router Advertisement from fe80::216:3eff:fe4b:d6bc I'm taling about the dhcpcd.sh included in the net-misc/netifrc-0.1 ebuild.
Created attachment 365062 [details, diff] Add sleep 2 to netifrc-0.1/net/dhcpcd.sh
This has been fixed here: http://roy.marples.name/projects/dhcpcd/ci/12934660bc?sbs=0
Think my problem relates to this one: 1. Configuring enp1s0 for dhcp: config_enp1s0="dhcp" 2. Starting the net interface only results in getting an ip address every other time: gentooTEST ~ # /etc/init.d/net.enp1s0 restart * Bringing up interface enp1s0 * dhcp ... * Sleeping for 2 seconds... * Running dhcpcd ... dhcpcd[21397]: version 6.2.0 starting dhcpcd[21397]: DUID 00:01:00:01:1a:82:40:83:00:0e:a6:39:c9:50 dhcpcd[21397]: enp1s0: IAID 85:98:70:65 dhcpcd[21397]: enp1s0: soliciting an IPv6 router dhcpcd[21397]: enp1s0: soliciting a DHCP lease dhcpcd[21397]: enp1s0: offered 10.136.235.223 from XXX.XXX.XXX.XXX dhcpcd[21397]: enp1s0: leased 10.136.235.223 for 72000 seconds dhcpcd[21397]: enp1s0: adding route to 10.136.0.0/16 dhcpcd[21397]: enp1s0: adding default route via 10.136.254.254 dhcpcd[21397]: forked to background, child pid 21461 [ ok ] * received address 10.136.235.223/16 [ ok ] gentooTEST ~ # /etc/init.d/net.enp1s0 restart * Bringing down interface enp1s0 * Stopping dhcpcd on enp1s0 ... [ ok ] * Removing addresses * Bringing up interface enp1s0 * dhcp ... * Sleeping for 2 seconds... * Running dhcpcd ... dhcpcd[22300]: version 6.2.0 starting dhcpcd[22300]: enp1s0: waiting for carrier dhcpcd[22300]: enp1s0: carrier acquired dhcpcd[22300]: DUID 00:01:00:01:1a:82:40:83:00:0e:a6:39:c9:50 dhcpcd[22300]: enp1s0: IAID 85:98:70:65 dhcpcd[22300]: enp1s0: soliciting an IPv6 router dhcpcd[22300]: enp1s0: rebinding lease of 10.136.235.223 dhcpcd[22300]: enp1s0: DHCP lease expired dhcpcd[22300]: enp1s0: soliciting a DHCP lease dhcpcd[22300]: enp1s0: no IPv6 Routers available dhcpcd[22300]: timed out dhcpcd[22300]: allowing 8 seconds for IPv4LL timeout dhcpcd[22300]: enp1s0: offered 10.136.235.223 from XXX.XXX.XXX.XXX dhcpcd[22300]: timed out dhcpcd[22300]: exited [ !! ] * ERROR: net.enp1s0 failed to start My dhcpcd is version 6.2.0-r1, but 5.6.4 gives same results (tried it already) My net-misc/netifrc is version 0.1 The sleep 2 fix, didn't fix my problem. Kernel is 3.10.25-gentoo.
Well sleeping for a few seconds is always problematic, since there will be cases where that X seconds will be not enough (for example, 2 was not enough for me, 10 did the trick). dhcpcd should try to obtain addresses forever. What if the IPv6 router with DHCP is not up, but will be available later? Or an IPv6 router goes down and another one comes up about the same time? Windows tries to obtain addresses forever, and nobody ever complained about that.
Well, I forgot to mention my main point, if dhcpcd starts, and a link local address is not present, check the interface later. If it has a link local address, then start probing for IPv6 addresses.
(In reply to Zoltán Halassy from comment #5) > Well, I forgot to mention my main point, if dhcpcd starts, and a link local > address is not present, check the interface later. If it has a link local > address, then start probing for IPv6 addresses. This if fixed in dhcpcd-6.4.0 where dhcpcd will add a link-local address if not one present.
This is a dhcpcd bug and it's fixed. Pretty sure this ticket can be closed now :)
The upstream dhcpcd bug has been fixed.
