Arch Linux

please run dhcpcd directly from the command line so it produces some useful output (add the debug flag together with other flags you may need).

It does not work here either when wired. I downgraded and put it in IgnorePkg in /etc/pacman.conf
Other also have problems with this update. There is no info on what you have changed in the packagebuild, so it is pretty hard to edit it and undo the changes.
Here is the forum post with ppl that have similar problems: http://bbs.archlinux.org/viewtopic.php?id=88663

ATM I cannot reproduce timeouts for eth0 connection (wasn't working in the morning, but now works).
However, it's still not working for wlan0 -- but I'm using wifi via networkmanager (kdemod-networkmanager-git 20091003-1).
If you know how to enable debug output for dhcpcd, when run through networkmanager, pls advise.
Currently, I have the following in /var/log/daemons.log:

Jan 14 21:45:22 cemmbk67 NetworkManager: <info> Activation (wlan0) Stage 3 of 5 (IP Configure Start) scheduled.
Jan 14 21:45:22 cemmbk67 NetworkManager: <info> Activation (wlan0) Stage 3 of 5 (IP Configure Start) started...
Jan 14 21:45:22 cemmbk67 NetworkManager: <info> (wlan0): device state change: 5 -> 7 (reason 0)
Jan 14 21:45:22 cemmbk67 NetworkManager: <info> Activation (wlan0) Beginning DHCP transaction (timeout in 45 seconds)
Jan 14 21:45:22 cemmbk67 dhcpcd: wlan0: reading lease `/var/lib/dhcpcd/dhcpcd-wlan0.lease'
Jan 14 21:45:22 cemmbk67 NetworkManager: <info> dhcpcd started with pid 4885
Jan 14 21:45:22 cemmbk67 NetworkManager: <info> Activation (wlan0) Stage 4 of 5 (IP6 Configure Get) scheduled...
Jan 14 21:45:22 cemmbk67 NetworkManager: <info> Activation (wlan0) Stage 3 of 5 (IP Configure Start) complete.
Jan 14 21:45:22 cemmbk67 NetworkManager: <info> Activation (wlan0) Stage 4 of 5 (IP6 Configure Get) started...
Jan 14 21:45:22 cemmbk67 NetworkManager: <info> Activation (wlan0) Stage 4 of 5 (IP6 Configure Get) complete.
Jan 14 21:45:22 cemmbk67 dhcpcd: sending commands to master dhcpcd process
Jan 14 21:45:22 cemmbk67 dhcpcd: wlan0: broadcasting for a lease
Jan 14 21:45:22 cemmbk67 dhcpcd: wlan0: sending DHCP_DISCOVER (xid 0x3c180eaf), next in 3.01 seconds
Jan 14 21:45:22 cemmbk67 dhcpcd: control command: /sbin/dhcpcd -B -K -L -c /usr/lib/networkmanager/nm-dhcp-client.action wlan0
Jan 14 21:45:22 cemmbk67 avahi-daemon[2275]: Registering new address record for fe80::222:fbff:fec3:143a on wlan0.*.
Jan 14 21:45:25 cemmbk67 dhcpcd: wlan0: sending DHCP_DISCOVER (xid 0x3c180eaf), next in 7.84 seconds
Jan 14 21:45:33 cemmbk67 dhcpcd: wlan0: sending DHCP_DISCOVER (xid 0x3c180eaf), next in 15.18 seconds
Jan 14 21:45:48 cemmbk67 dhcpcd: wlan0: sending DHCP_DISCOVER (xid 0x3c180eaf), next in 32.71 seconds
Jan 14 21:46:21 cemmbk67 dhcpcd: wlan0: sending DHCP_DISCOVER (xid 0x3c180eaf), next in 63.90 seconds
etc... (without timeout set it lasts forever)

@linfan: http://mailman.archlinux.org/pipermail/arch-dev-public/2010-January/014824.html

@alyst: I suppose you should be able to just add the debug option to /etc/dhcpcd.conf like one would do with other commandline options. From the upstream changelog I don't see anything which should cause this on first glance.

@linfan: http://mailman.archlinux.org/pipermail/arch-dev-public/2010-January/014824.html

@alyst: I suppose you should be able to just add the debug option to /etc/dhcpcd.conf like one would do with other commandline options. From the upstream changelog I don't see anything which should cause this on first glance.

My command line output for "dhcpcd -d" :

dhcpcd: version 5.1.4 starting
dhcpcd: eth0: executing `/usr/lib/dhcpcd/dhcpcd-run-hooks', reason PREINIT
dhcpcd: eth0: executing `/usr/lib/dhcpcd/dhcpcd-run-hooks', reason CARRIER
dhcpcd: eth0: reading lease `/var/lib/dhcpcd/dhcpcd-eth0.lease'
dhcpcd: eth0: broadcasting for a lease
dhcpcd: eth0: sending DHCP_DISCOVER (xid 0x34207770), next in 4.71 seconds
dhcpcd: eth0: sending DHCP_DISCOVER (xid 0x34207770), next in 7.23 seconds
dhcpcd: eth0: sending DHCP_DISCOVER (xid 0x34207770), next in 15.12 seconds
dhcpcd: eth0: sending DHCP_DISCOVER (xid 0x34207770), next in 32.97 seconds
dhcpcd: timed out

Removing /var/lib/dhcpcd/dhcpcd-eth0.lease prevent this problem to occur.

Does this mean that if I want to use the new dhcpcd, I will have to
1. first become root and do rm /var/lib/dhcpcd/dhcpcd-eth0.lease and then
2. /etc/rc.d/network restart
3. /etc/rc.d/gw6c restart
4. /etc/rc.d/openntpd restart?

Or is there some script to automate this and in that case in which file to do it?

@linfan: the -k switch to dhcpcd releases the previous lease and thus effectively removes that file. Can you confirm that the previous lease is indeed the problem here for you guys? [edit] never mind, I just saw on bbs that it indeed fixes the problem

created an upstream ticket: http://roy.marples.name/projects/dhcpcd/ticket/185

Interesting. I cannot replicate this.

Can someone attach a full tcpdump (-s0 -w/tmp/dhcp.cap) of the DHCP transactions from a working dhcpcd-5.1.3 and a non working dhcpcd-5.1.4 please?

I have not been able to reproduce either. Here is some info that may help. From my post in the forums:http://bbs.archlinux.org/viewtopic.php?id=88792

dhcpcd --debug eth1
dhcpcd: version 5.1.4 starting
dhcpcd: eth1: executing `/usr/lib/dhcpcd/dhcpcd-run-hooks', reason PREINIT
dhcpcd: eth1: executing `/usr/lib/dhcpcd/dhcpcd-run-hooks', reason CARRIER
dhcpcd: eth1: reading lease `/var/lib/dhcpcd/dhcpcd-eth1.lease'
dhcpcd: eth1: broadcasting for a lease
dhcpcd: eth1: sending DHCP_DISCOVER (xid 0xa30f717), next in 3.38 seconds
dhcpcd: eth1: sending DHCP_DISCOVER (xid 0xa30f717), next in 8.56 seconds
dhcpcd: eth1: sending DHCP_DISCOVER (xid 0xa30f717), next in 16.82 seconds
dhcpcd: eth1: wrong xid 0x2f778173 (expecting 0xa30f717) from xxx.xxx.xxx.xxx
dhcpcd: eth1: sending DHCP_DISCOVER (xid 0xa30f717), next in 32.71 seconds
dhcpcd: timed out

The old lease was issued on the 14th of Dec, I'm guessing (but not sure) that it was issued by my Linksys router at home. When I had the problem seen above, I had just updated my system via wireless (which seems to not had this problem). I connected the ethernet cable at work where a Windows server issues the lease. As far as I know, there was only one dhcpcd update during this time.

Attached : my tcpdump records from a working dhcpcd-5.1.3 and a non working dhcpcd-5.1.4

I do not quite follow what I am supposed to do. Could you please type the exact command I am supposed to execute. If I do: -s0 -w/tmp/dhcp.cap, I get bash: -s0: command not found and if I do dhcpcd --debug eth0, I get dhcpcd: dhcpcd already running on pid 1864 (/var/run/dhcpcd-eth0.pid).

The -k switch I did not either understand how to do, but I did the following to my dhcpcd.conf, I hope it was correct--I hashed nohook and added release before lookup-hostname. I will turn off the puter soon and go to sleep. Hopefully it gets on line tomorrow:

-------
# A hook script is provided to lookup the hostname if not set by the DHCP
# server, but it should not be run by default.
#nohook
release lookup-hostname
noipv4ll

Basically, do this in one console
tcpdump -s0 -w/tmp/dhcp.cap -ieth0
And this in another console
dhcpcd -d eth0

Once done, terminate tcpdump with ctrl-c. Rinse and repeat with the other version.
I need both files. The captures above are the plaintext outputs which are useless to me sadly.

Cannot reproduce this now. There are a lot of other things going crazy, too, like timidity++. Dunno where to look for errors. Usually with time stuff settles in archlinux. Sorry. I will downgrade dhcpcd for now and put it in /etc/pacman.conf in IgnorePkg

Trying to fix timidity++, following some advice i got this message. Dunno if it has anything to do with this problem. It is gnome, but I will post it here for you to see.

gconftool-2 -t string --set /system/gstreamer/0.10/default/musicaudiosink alsasink
Error setting value: Failed to contact configuration server; some possible causes are that you need to enable TCP/IP networking for ORBit, or you have stale NFS locks due to a system crash. See http://projects.gnome.org/gconf/ for information. (Details - 1: Failed to get connection to session: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.)

I'm quite new. I tried to do the procedure to obtain the tcpdump files, and when I reinstalled dhcpcd5.1.4 and tried to reproduce the bug I could not, that is it connected without any problems. Strange thing is that I upgraded from pacman's cache.
If I can be of more help I will gladly help but I might need some guidance.
I will attach both files in any case, let me know if I can do more.

I've got the same problem, Arch64 and dhcpcd 5.1.4-1.
I get this behavior working from the office, at home DHCP via wireless lan works perfectly.

I can also say that using dhclient (4.1.0.p1-2) to get the address works when dhcpcd fails. Can anybody confirm this?

@eazy: please attach the tcdump output for both dhcpcd versions as requested above by Roy

I tried installing dhcpcd 5.1.3-1 (http://arm.konnichi.com/core/os/x86_64/dhcpcd-5.1.3-1-x86_64.pkg.tar.gz) and it works with this version.

I tried reinstalling dhcpcd 5.1.4-1 and I cannot reproduce the bug.. Strange behavior.

@pressh: I would, but it seems to work with the latest version now, after trying the old version. I'll post the tcpdump as soon as I re-experience it.

The problem returned today, here are the tcpdump files.

dhcpcd-5.1.3 "working" attachment just shows a DHCP REQUEST from iPod-touch-3 (ie, not dhcpcd)
dhcpcd-5.1.4 shows valid DHCP requests without a reply back from the server.
However, it is constantly requesting an IP address. I'm guessing that your DHCP server is non authoratitive and this has exposed a possible bug in dhcpcd where we request the lease but fail to clear the request address on a short timeout.

Can I please have some confirmations that dhcpcd 5.1.4-2 in the testing repo fixes the problem. It is safe to only install that package from the testing repo if you don't have [testing] enabled as it does not depend on anything else in testing. I'm sure you guys know how to do so.

Dhcpcd 5.1.4-2 doesn't fix the problem. Symptoms are the same. I tested with i686 and x86_64 packages, on my two computers.

tcpdumps of it not working would be nice :)

seems that this is breaking some stuff: http://bbs.archlinux.org/viewtopic.php?pid=695910

The testing dhcpcd does not work here and tcdump fails. Downgraded back to 5.1.3-1

I can't imagine how tcpdump would just fail?

it said there was no ipv4 or something - nothing much more. I am happy with 5.1.3. I wonder if this peculiarity only affects amd's running 64. On my old amd64 that runs 32 bits there is no problem. But I am clueless. Both new dhcpcd's fail on my amd64 desktop and laptop.

My apologies for requesting a re-open of the duplicate. I did not read the reason for closing.

I have problem after upgrade to dhcpcd-5.1.4-2. I use Wicd (and dhcpcd) for connecting.

dhcpcd-5.1.4-1:
[root@lenovo pkg]# dhcpcd
dhcpcd: version 5.1.4 starting
dhcpcd: wlan0: broadcasting for a lease
dhcpcd: eth0: waiting for carrier
dhcpcd: wlan0: offered 192.168.1.142 from 192.168.1.1
dhcpcd: wlan0: acknowledged 192.168.1.142 from 192.168.1.1
dhcpcd: wlan0: checking for 192.168.1.142
dhcpcd: wlan0: leased 192.168.1.142 for 86400 seconds
dhcpcd: forking to background

So, All OK


dhcpcd-5.1.4-2:
[root@lenovo home]# dhcpcd
dhcpcd: version 5.1.4 starting
dhcpcd: wlan0: broadcasting for a lease
dhcpcd: eth0: waiting for carrier
dhcpcd: wlan0: offered 192.168.1.142 from 192.168.1.1
dhcpcd: wlan0: NAK: lease not found from 192.168.1.1
dhcpcd: wlan0: broadcasting for a lease
dhcpcd: wlan0: offered 192.168.1.142 from 192.168.1.1
dhcpcd: wlan0: NAK: lease not found from 192.168.1.1
.
.
.
dhcpcd: timed out

NOT WORKS!

@Alois: can we have a tcpdump of both as described by Roy here: http://bugs.archlinux.org/task/17838#comment55944

I have the same behavior as @anespor.... dhcpcd-5.1.4-2 timeouts. My dhcpd server says that my dhcpcd tries to request address 0.0.0.0.

Jan 26 18:00:54 fw dhcpd: DHCPDISCOVER from 00:21:70:f4:3d:15 via eth0
Jan 26 18:00:54 fw dhcpd: DHCPOFFER on 200.1.19.55 to 00:21:70:f4:3d:15 via eth0
Jan 26 18:00:54 fw dhcpd: DHCPREQUEST for 0.0.0.0 from 00:21:70:f4:3d:15 via eth0: unknown lease 0.0.0.0.

I just stumbled across the same problem, just that I can't reproduce it all the time, but just "sometimes".
I downgraded dhcpcd now to 5.1.4-1, which works absolutely properly "for me".

Same problem here. If you need some additional input/logs let me know.

Btw:
Are you sure that the duplicated bug is really related?
I do NOT have that bug with -1 but with -2.

i have the problem since upgrading to dhcpcd-5.1.4-2 today. Currently it seems that i can reproduce it every time. Here is a dhcpcd -d:

dhcpcd: version 5.1.4 starting
dhcpcd: eth0: executing `/usr/lib/dhcpcd/dhcpcd-run-hooks', reason PREINIT
dhcpcd: eth0: executing `/usr/lib/dhcpcd/dhcpcd-run-hooks', reason CARRIER
dhcpcd: eth0: broadcasting for a lease
dhcpcd: eth0: sending DHCP_DISCOVER (xid 0x3ef1822a), next in 3.44 seconds
dhcpcd: eth0: discarding expired lease
dhcpcd: eth0: offered 192.168.0.19 from 192.168.0.1
dhcpcd: eth0: sending DHCP_REQUEST (xid 0x3ef1822a), next in 4.69 seconds
dhcpcd: eth0: reject NAK
dhcpcd: eth0: sending DHCP_REQUEST (xid 0x3ef1822a), next in 3.82 seconds
dhcpcd: eth0: reject NAK
...
...
dhcpcd: timed out

yeah of course, sry
and the output of the working version:
dhcpcd: version 5.1.4 starting
dhcpcd: eth0: executing `/usr/lib/dhcpcd/dhcpcd-run-hooks', reason PREINIT
dhcpcd: eth0: executing `/usr/lib/dhcpcd/dhcpcd-run-hooks', reason CARRIER
dhcpcd: eth0: broadcasting for a lease
dhcpcd: eth0: sending DHCP_DISCOVER (xid 0x6febeb71), next in 4.21 seconds
dhcpcd: eth0: offered 192.168.0.19 from 192.168.0.1
dhcpcd: eth0: sending DHCP_REQUEST (xid 0x6febeb71), next in 3.71 seconds
dhcpcd: eth0: acknowledged 192.168.0.19 from 192.168.0.1
dhcpcd: eth0: leased 192.168.0.19 for 864000 seconds
dhcpcd: eth0: adding IP address 192.168.0.19/24
dhcpcd: eth0: adding route to 192.168.0.0/24
dhcpcd: eth0: adding default route via 192.168.0.1
dhcpcd: eth0: writing lease `/var/lib/dhcpcd/dhcpcd-eth0.lease'
dhcpcd: eth0: executing `/usr/lib/dhcpcd/dhcpcd-run-hooks', reason BOUND
dhcpcd: forking to background

In a minute I'll upload a git checkout in [testing] which has another fix to the problem, please test if it works better

thank you, that works for me :)
here is the output in case you need it:

dhcpcd: version 5.1.4 starting
dhcpcd: eth0: executing `/usr/lib/dhcpcd/dhcpcd-run-hooks', reason PREINIT
dhcpcd: eth0: executing `/usr/lib/dhcpcd/dhcpcd-run-hooks', reason CARRIER
dhcpcd: eth0: broadcasting for a lease
dhcpcd: eth0: sending DHCP_DISCOVER (xid 0x71c46fcc), next in 3.45 seconds
dhcpcd: eth0: offered 192.168.0.19 from 192.168.0.1
dhcpcd: eth0: sending DHCP_REQUEST (xid 0x71c46fcc), next in 3.42 seconds
dhcpcd: eth0: acknowledged 192.168.0.19 from 192.168.0.1
dhcpcd: eth0: checking for 192.168.0.19
dhcpcd: eth0: sending ARP probe (1 of 3), next in 1.59 seconds
dhcpcd: eth0: sending ARP probe (2 of 3), next in 1.20 seconds
dhcpcd: eth0: sending ARP probe (3 of 3), next in 2.00 seconds
dhcpcd: eth0: leased 192.168.0.19 for 864000 seconds
dhcpcd: eth0: adding IP address 192.168.0.19/24
dhcpcd: eth0: adding route to 192.168.0.0/24
dhcpcd: eth0: adding default route via 192.168.0.1
dhcpcd: eth0: writing lease `/var/lib/dhcpcd/dhcpcd-eth0.lease'
dhcpcd: eth0: executing `/usr/lib/dhcpcd/dhcpcd-run-hooks', reason BOUND
dhcpcd: forking to background

dhcpcd 5.1.5git20100127-1 from testing works for me.
dhcpcd 5.1.4-2 was not working in 100/100 cases.

This git snapshot seems to have fixed my problems, thanks!

dhcpcd 5.1.5git20100127-1 from testing works for me also. Thanks!

can someone who had problems with the initial 5.1.4-1 release confirm that it is also fixed for them please?

I confirm that dhcpcd 5.1.5git20100127-1 (i686 and x86_64) fixes the issue, on my two computers.
5.1.4-1 and 5.1.4.2 weren't working for me.
I took my time to test (to be sure) and there are no failures.

the git version also works for me

5.1.5-git version working with my WiFi router (tried wired/wireless connections).

Thus far working here, too.

I'll wait for the 5.1.5 release this weekend and get that into [core].

dhcpcd-5.1.5 released

I'm getting "dhcpcd: timed out" for my eth0. dhcpcd v5.2.2

I have double-checked all my settings and still nothing. I can't connect eth0!

The current release/version in the repos is 5.2.5, please update to the latest version and see if the problem remains. Also please open a new report, this one was fixed half a year ago and should be unrelated to your error.

while your at it, file also an upstream report, he most likely needs a tcpdump for the latest working version and the current not-working current version. Check for the Roy's comments in this bug report how to do so.