FS#37112 - [dhcpcd] forks to background too early on dual-stack connections

Attached to Project: Arch Linux
Opened by Radu Potop (wooptoo) - Saturday, 28 September 2013, 18:19 GMT
Last edited by Doug Newgard (Scimmia) - Wednesday, 13 May 2015, 22:27 GMT
Task Type Bug Report
Category Packages: Core
Status Closed
Assigned To Ronald van Haren (pressh)
Architecture All
Severity Medium
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 2
Private No

Details

I have a dual-stack internet connection and I use the dhcpcd@eth0.service at bootup. Dhcpcd forks to background right after the DHCPv6 lease is obtained, causing the network.target to appear as ready. This in turn causes some services that depend on internet connection to fail. Then it finally gets the DHCPv4 lease.

The attached log clears things up:

dhcpcd starts
dhcpcd gets an DHCPv6 lease
dhcpcd forks to background, causing the network to appear as ready
services such as minidlna and transmission fail
dhcpcd finally gets DHCPv4 lease

The service is started with `dhcpcd -q -w eth0` so in theory it *should* wait for a lease.

This does not happen when starting dhcpcd manually from the command line after booting.
   dhcpcd.txt (2.1 KiB)
This task depends upon

Closed by  Doug Newgard (Scimmia)
Wednesday, 13 May 2015, 22:27 GMT
Reason for closing:  Fixed
Comment by Dave Reisner (falconindy) - Saturday, 28 September 2013, 18:25 GMT
Looks a bit like:

http://roy.marples.name/projects/dhcpcd/ticket/242
Comment by Radu Potop (wooptoo) - Monday, 30 September 2013, 07:05 GMT
I don't know if we can do anything about it. Report upstream maybe?
Comment by Roy Marples (rsmarples) - Friday, 18 October 2013, 11:44 GMT
The problem is that some services expect ipv4, some ipv6 and some both.
dhcpcd cannot possible know which protocols are needed for a clean boot, so it's behaviour is to fork once one of the protocols complete.
However, it's obvious that the user might be able to specify a preference, so this patch was added over a week ago:
http://roy.marples.name/cgi-bin/gitweb.cgi?p=dhcpcd.git;a=commit;h=fbfa80330d336b8cae03c6da4e67535dc25b7ee6

Hopefully a new dhcpcd release soon.
Comment by Radu Potop (wooptoo) - Saturday, 26 October 2013, 15:10 GMT
I noticed that if I run dhcpcd with the parameters: dhcpcd -4 -q -w eth0
It will fork to background on IPv4 connection, BUT it will also get an IPv6 address as soon as it is available.
This IS actually the behaviour that I want, but it's funny that it also gets an IPv6 address, when I specified that it should get IPv4 only.

Can this happen because of SLAAC or maybe it is a bug in dhcpcd?
Comment by Roy Marples (rsmarples) - Friday, 08 November 2013, 10:51 GMT
It's probably the kernel handling SLAAC.

By default dhcpcd lets the kernel handle that still, but it will request an RA. As you're using the -4 that, it shouldn't be requesting the RA via an RS but equally dhcpcd won't stop the kernel doing that either.
Comment by Roy Marples (rsmarples) - Monday, 14 July 2014, 12:06 GMT
This ticket can probably be closed now, unless it's a netctl bug.
Comment by Christian Hesse (eworm) - Tuesday, 02 September 2014, 06:42 GMT
Do do have this issue with dhcpcd as well, though not with any service dependencies:
Using wicd to control my network connection here. wicd starts dhcpcd, which gets an IPv6 address and forks to background. wicd then kills dhcp as it did not find a valid IPv4 address on the interface. My solution is to simply add

waitip 4

to dhcpcd.conf. This makes dhcpcd wait for an IPv4 address before forking to background. Probably this also works for services and their dependencies.
Comment by Doug Newgard (Scimmia) - Wednesday, 13 May 2015, 22:27 GMT
eworm, your specific issue has been filed under  FS#41216 . As it appears the main bug here is taken care of, I'm going to close this one.

Loading...