You are not logged in.

#1 2014-11-21 06:57:34

bachtiar
Member
Registered: 2005-02-08
Posts: 64

[SOLVED] Retry failed DHCP request

I am using systemd unit dhcpcd@eth0.service to get a IPv4 address on boot.

If there is no network connection when machine boots (ie. cable unplugged, dhcp server not ready), dhcpcd exits and the machine never gets an IP address.

How can I tell dhcpcd to keep trying forever?

Would it be any different if I moved to netctl for bringing up my network connection?

Thanks!

Last edited by bachtiar (2014-11-25 17:58:20)

Offline

#2 2014-11-21 11:30:59

rsmarples
Member
Registered: 2009-05-12
Posts: 287

Re: [SOLVED] Retry failed DHCP request

Use dhcpcd.service instead of the per interface one.
OR set timeout to 0 OR add the -M flag in dhcpcd@eth0.service

Offline

#3 2014-11-21 19:32:07

Leonid.I
Member
From: Aethyr
Registered: 2009-03-22
Posts: 999

Re: [SOLVED] Retry failed DHCP request

@bachtiar:
Personally, I use netctl to only set up the interface (i.e. IP=no) and then order a dhcpcd@<interface>.service after the corresponding netctl. In the true systemd spirit I also put -B to run it in foreground.

@rsmarples:
Does dhcpcd -M fork immidiately? And does the timeout setting have any effect when running with this flag? The reason why I am asking, is that netctl is basically a bash script that  calls dhcpcd, so having -t 0 is not good because systemd will stop the boot process until netctl finishes.

Thanks.


Arch Linux is more than just GNU/Linux -- it's an adventure
pkill -9 systemd

Offline

#4 2014-11-21 19:39:05

WonderWoofy
Member
From: Los Gatos, CA
Registered: 2012-05-19
Posts: 8,414

Re: [SOLVED] Retry failed DHCP request

@Leonid.I, from what I have gathered from rsmaples' previos posts (he is the author of dhcpcd), dhcpcd is actually intended to be simply run.  It has the ability to detect interfaces going up and down and network connectivity.  It is only because of the choices made by the network management utilities, that it is called specifically on a given interface only when needed.

Offline

#5 2014-11-23 16:30:37

bachtiar
Member
Registered: 2005-02-08
Posts: 64

Re: [SOLVED] Retry failed DHCP request

@rsmaples:
Does setting timeout to 0 cause dhcpcd to retransmit requests periodically? Because if not, waiting forever is completely useless.
As for -M, it causes dhcpcd to operate on multiple interfaces, right? I can't see why it would apply here.

@WonderWoofy:
Acting on network interface coming up or down cannot help - the cable might be connected all the time, but the DHCP server might not be responding.

In contrast, there is another DHCP client, called dhclient. It is designed to run in background all the time, because the authors realised DHCP lease does not last forever and should be renewed when it expires. So it seems to me that dhcpcd is ignoring the basic principles of DHCP protocol and can therefore not be considered for serious use. I find it rather surprising that it is the default choice in Arch.

For example, CentOS uses dhclient and has a "persistent" attribute for configuring DHCP IP, which does exacly that - it keeps trying if it cannot get a lease at boot, and renews the lease before it would expire.

Offline

#6 2014-11-23 17:15:14

ewaller
Administrator
From: Pasadena, CA
Registered: 2009-07-13
Posts: 19,740

Re: [SOLVED] Retry failed DHCP request

Bachtiar,
I think your interpretation is incorrect.   dhcpcd is a daemon and it does handle expiring leases as one would expect.  When WonderWoofy stated that the author intended that it be 'simply run', that means only how it is launched.  Once launched it forks to the background where it works its magic.    The question is this the right way to do it, or to run it as a service, or on a global basis, or on an interface by interface basis.  In all the various modes, it is still is a daemon.


Nothing is too wonderful to be true, if it be consistent with the laws of nature -- Michael Faraday
Sometimes it is the people no one can imagine anything of who do the things no one can imagine. -- Alan Turing
---
How to Ask Questions the Smart Way

Offline

#7 2014-11-24 01:39:46

Leonid.I
Member
From: Aethyr
Registered: 2009-03-22
Posts: 999

Re: [SOLVED] Retry failed DHCP request

bachtiar wrote:

Does setting timeout to 0 cause dhcpcd to retransmit requests periodically?

Yes. It will wait until the DHCP server responds. I use it this way to start dhcpcd before wpa_supplicant (so it has to wait ~5 sec for association and auth to complete).

bachtiar wrote:

Acting on network interface coming up or down cannot help - the cable might be connected all the time, but the DHCP server might not be responding.

This is covered by the "-t 0" switch.

bachtiar wrote:

In contrast, there is another DHCP client, called dhclient. It is designed to run in background all the time, because the authors realised DHCP lease does not last forever and should be renewed when it expires. So it seems to me that dhcpcd is ignoring the basic principles of DHCP protocol and can therefore not be considered for serious use. I find it rather surprising that it is the default choice in Arch.

For example, CentOS uses dhclient and has a "persistent" attribute for configuring DHCP IP, which does exacly that - it keeps trying if it cannot get a lease at boot, and renews the lease before it would expire.

dhcpcd does all this and much more. In my experience, it is superior to dhclient.

Last edited by Leonid.I (2014-11-24 01:40:24)


Arch Linux is more than just GNU/Linux -- it's an adventure
pkill -9 systemd

Offline

#8 2014-11-24 01:45:43

Leonid.I
Member
From: Aethyr
Registered: 2009-03-22
Posts: 999

Re: [SOLVED] Retry failed DHCP request

WonderWoofy wrote:

@Leonid.I, from what I have gathered from rsmaples' previos posts (he is the author of dhcpcd), dhcpcd is actually intended to be simply run.  It has the ability to detect interfaces going up and down and network connectivity.  It is only because of the choices made by the network management utilities, that it is called specifically on a given interface only when needed.

Yes, I know that dhcpcd is actually a network management utility rather than a dumb client.

But in fact, that's what I want it to be -- a dumb client because we already have netctl for managing network interfaces, which has a clean and transparent logic (so it is also dumb in some sense). I mean, if I wanted something obscure I'd use systemd-networkd or (heaven forbid) NetworkManager.


Arch Linux is more than just GNU/Linux -- it's an adventure
pkill -9 systemd

Offline

#9 2014-11-24 11:13:02

rsmarples
Member
Registered: 2009-05-12
Posts: 287

Re: [SOLVED] Retry failed DHCP request

Leonid.I wrote:

@bachtiar:
@rsmarples:
Does dhcpcd -M fork immidiately? And does the timeout setting have any effect when running with this flag? The reason why I am asking, is that netctl is basically a bash script that  calls dhcpcd, so having -t 0 is not good because systemd will stop the boot process until netctl finishes.

No and No.
I the systemd case, netcl could add the -b flag which forces dhcpcd into the background right away where it can continue on it's merry.
Or it could do this
exec dhcpcd -B $more_flags
exec would replace the current process image with dhcpcd, but I don't know netctl or systemd well enough to know if that would work. If it does work, it would be the better approach.

Offline

#10 2014-11-24 11:25:22

rsmarples
Member
Registered: 2009-05-12
Posts: 287

Re: [SOLVED] Retry failed DHCP request

bachtiar wrote:

@rsmaples:
Does setting timeout to 0 cause dhcpcd to retransmit requests periodically? Because if not, waiting forever is completely useless.
As for -M, it causes dhcpcd to operate on multiple interfaces, right? I can't see why it would apply here.

Yes.
-M applies because it won't exit on interface timeout.

@WonderWoofy:
Acting on network interface coming up or down cannot help - the cable might be connected all the time, but the DHCP server might not be responding.

In contrast, there is another DHCP client, called dhclient. It is designed to run in background all the time, because the authors realised DHCP lease does not last forever and should be renewed when it expires. So it seems to me that dhcpcd is ignoring the basic principles of DHCP protocol and can therefore not be considered for serious use. I find it rather surprising that it is the default choice in Arch.

For example, CentOS uses dhclient and has a "persistent" attribute for configuring DHCP IP, which does exacly that - it keeps trying if it cannot get a lease at boot, and renews the lease before it would expire.

Ah so you're the author of the Arch ticket I commented on.
I strongly suggest refraining from such comments in the future as you clearly do not know what you are talking about.

As a quick test, do this
1) open a terminal
2) kill all dhcp processes (dhcpcd, dhclient, etc)
3) start dhcpcd with no arguments, like so: dhcpcd

Please do that test with the cable disconnected or the DHCP sever down.
Reconnect the cable or bring the server back up.
Wait a minute or so (dhcpcd will test for a DHCP server every few seconds, gradually slowing down until 1 request a minute, hence waiting at least one minute).
Wait another 10 seconds to allow for ARP testing duplicate addresses and I think you'll find a tasty IPv4 address.

Last edited by rsmarples (2014-11-24 11:34:49)

Offline

#11 2014-11-24 11:33:14

rsmarples
Member
Registered: 2009-05-12
Posts: 287

Re: [SOLVED] Retry failed DHCP request

Leonid.I wrote:
bachtiar wrote:

Does setting timeout to 0 cause dhcpcd to retransmit requests periodically?

Yes. It will wait until the DHCP server responds. I use it this way to start dhcpcd before wpa_supplicant (so it has to wait ~5 sec for association and auth to complete).

bachtiar wrote:

Acting on network interface coming up or down cannot help - the cable might be connected all the time, but the DHCP server might not be responding.

This is covered by the "-t 0" switch.

It was brought to my attention recently that there was a bug with -t 0 and the dhcpcd-6.6 series which is fixed here:
http://roy.marples.name/projects/dhcpcd … 67cc?sbs=0

The bug was caused by changing to a new ARP state engine (basically >1 ARP state is now possible which opens the way for DNAv4 in the future if needed) which in turn changed the way IPv4LL is triggered and thus the code to extend the timeout because of this was removed, hence the bug.

Leonid.I wrote:

dhcpcd does all this and much more. In my experience, it is superior to dhclient.

I do like the sound of a statisfied dhcpcd user smile
Now, if only dhcpcd-gtk or dhcpcd-qt from the dhcpcd-ui project was available in Arch ..... but that's a whole nother story!

Last edited by rsmarples (2014-11-24 11:33:54)

Offline

#12 2014-11-24 12:02:31

bachtiar
Member
Registered: 2005-02-08
Posts: 64

Re: [SOLVED] Retry failed DHCP request

Leonid.I wrote:

This is covered by the "-t 0" switch.

I've tried adding -t 0 to /usr/lib/systemd/system/dhcpcd@.service, like so:

ExecStart=/usr/bin/dhcpcd -q -t 0 -w %I

With network cable connected and DHCP server not responding, dhcpcd-6.4.0-1 still exits after approx. 1 minute.

However, if I run it manually with "dhcpcd -t 0 -w eth0", it indeed keeps running, just as rsmaples said. Could this then be an issue with systemd?

ewaller wrote:

dhcpcd is a daemon and it does handle expiring leases as one would expect.

If dhcpcd is not running, it obviously cannot keep track of lease expiration. So, assuming the above, the two issues are really just one: the problem of dhcpcd exiting when stared via systemd at boot.

Leonid.I wrote:

dhcpcd does all this and much more. In my experience, it is superior to dhclient.

I much prefer dhcpcd over bloated dhclient myself, but a server without IP is a deal breaker.

rsmarples wrote:

I strongly suggest refraining from such comments in the future as you clearly do not know what you are talking about.

Sorry, I did not mean to offend anyone, it just seemed like a right thing to do based on information I had at that moment.

Offline

#13 2014-11-24 13:08:33

rsmarples
Member
Registered: 2009-05-12
Posts: 287

Re: [SOLVED] Retry failed DHCP request

bachtiar wrote:

However, if I run it manually with "dhcpcd -t 0 -w eth0", it indeed keeps running, just as rsmaples said. Could this then be an issue with systemd?

I don't use systemd so I have no idea.

Offline

#14 2014-11-24 19:19:01

Leonid.I
Member
From: Aethyr
Registered: 2009-03-22
Posts: 999

Re: [SOLVED] Retry failed DHCP request

rsmarples wrote:

No and No.
I the systemd case, netcl could add the -b flag which forces dhcpcd into the background right away where it can continue on it's merry.
Or it could do this
exec dhcpcd -B $more_flags
exec would replace the current process image with dhcpcd, but I don't know netctl or systemd well enough to know if that would work. If it does work, it would be the better approach.

Right, this is something that needs to be fixed in netctl because currently it calls dhcpcd with a default timeout of 30s which can slow the boot is the DHCP server is slow to respond...

rsmarples wrote:

It was brought to my attention recently that there was a bug with -t 0 and the dhcpcd-6.6 series which is fixed here:
http://roy.marples.name/projects/dhcpcd … 67cc?sbs=0

The bug was caused by changing to a new ARP state engine (basically >1 ARP state is now possible which opens the way for DNAv4 in the future if needed) which in turn changed the way IPv4LL is triggered and thus the code to extend the timeout because of this was removed, hence the bug.

Thanks for fixing it... But I haven't noticed that issue. Do I have to use ipv4ll to trigger it?

rsmarples wrote:

Now, if only dhcpcd-gtk or dhcpcd-qt from the dhcpcd-ui project was available in Arch ..... but that's a whole nother story!

dhcpcd-ui is available in AUR: https://aur.archlinux.org/packages/dhcpcd-ui/ ...


Arch Linux is more than just GNU/Linux -- it's an adventure
pkill -9 systemd

Offline

#15 2014-11-24 19:27:24

Leonid.I
Member
From: Aethyr
Registered: 2009-03-22
Posts: 999

Re: [SOLVED] Retry failed DHCP request

bachtiar wrote:
Leonid.I wrote:

This is covered by the "-t 0" switch.

I've tried adding -t 0 to /usr/lib/systemd/system/dhcpcd@.service, like so:

ExecStart=/usr/bin/dhcpcd -q -t 0 -w %I

With network cable connected and DHCP server not responding, dhcpcd-6.4.0-1 still exits after approx. 1 minute.

However, if I run it manually with "dhcpcd -t 0 -w eth0", it indeed keeps running, just as rsmaples said. Could this then be an issue with systemd?

There is no issue, just a misunderstanding smile Most likely you have the dhcpcd@.service of Type=forking (the default). So, systemd waits until the daemon forks, which never happens, and kills it after a timeout. I think either of the following will work: (i) add "-b" flag and keep Type=forking; (ii) make the service Type=simple and change "-w" to "-B" on the dhcpcd command line.


Arch Linux is more than just GNU/Linux -- it's an adventure
pkill -9 systemd

Offline

#16 2014-11-25 06:50:09

bachtiar
Member
Registered: 2005-02-08
Posts: 64

Re: [SOLVED] Retry failed DHCP request

Leonid.I wrote:

Most likely you have the dhcpcd@.service of Type=forking (the default). So, systemd waits until the daemon forks, which never happens, and kills it after a timeout. I think either of the following will work: (i) add "-b" flag and keep Type=forking; (ii) make the service Type=simple and change "-w" to "-B" on the dhcpcd command line.

-b did the trick. Thanks!

Offline

Board footer

Powered by FluxBB