Arch Linux

Could that be a little more verbose please? Can you attach debug output from dhcpcd (I believe the -d option will give you some, look at the manpage).

[@ root adriana ] # dhcpcd -d wlan0 # [P ~twey ] [J 0 ] [L 136 ]
wlan0: dhcpcd 4.0.2 starting
wlan0: hardware address = 00:19:d2:1a:cb:fc
wlan0: executing `/usr/lib/dhcpcd/dhcpcd-run-hooks', reason PREINIT
wlan0: broadcasting for a lease
wlan0: sending DHCP_DISCOVER with xid 0x1a24e9b3, next in 3.69 seconds
wlan0: sending DHCP_DISCOVER with xid 0x1a24e9b3, next in 8.92 seconds
wlan0: sending DHCP_DISCOVER with xid 0x1a24e9b3, next in 15.14 seconds
wlan0: sending DHCP_DISCOVER with xid 0x1a24e9b3, next in 31.87 seconds
wlan0: timed out
wlan0: trying to use old lease in `/var/lib/dhcpcd/dhcpcd-wlan0.lease'
wlan0: probing for an IPV4LL address
wlan0: checking 169.254.104.54 is available on attached networks
wlan0: sending ARP probe (1 of 3), next in 1.85 seconds
wlan0: sending ARP probe (2 of 3), next in 1.18 seconds
wlan0: sending ARP probe (3 of 3), next in 2.00 seconds
wlan0: using IPv4LL address 0.0.0.0
wlan0: adding IP address 169.254.104.54/16
wlan0: executing `/usr/lib/dhcpcd/dhcpcd-run-hooks', reason IPV4LL
wlan0: forking to background

It simply times out. I find that `rmmod iwl3945;modprobe iwl3945` and trying again temporarily fixes the problem, but the connection drops when the lease expires and I have to do it again.

dhcpcd use a new /etc/dhcpcd.conf file.
you may want to review the option there.

In your description, you say it was tested against Intel 4965, but in comment#2 you are dealing with the iwl3945 module which has nothing to do with the 4965. The module for Intel 4965 is 'iwlagn'.

As a side note, dhcpcd works fine for me w/ iwlagn, system fully updated

i have the same problem...

# dhcpcd eth1
eth1: dhcpcd 4.0.2 starting
eth1: broadcasting for a lease
eth1: timed out
eth1: trying to use old lease in `/var/lib/dhcpcd/dhcpcd-eth1.lease'
eth1: probing for an IPV4LL address
eth1: checking 169.254.114.180 is available on attached networks
eth1: using IPv4LL address 0.0.0.0


wan card: Broadcom Corporation BCM4312 802.11b/g
all worked fine a week ago...

I think I can confirm using both the ndiswrapper and ath9k-driver for an Atheros 5008-chipset.

dhclient works fine, but dhcpcd keeps timing out since upgrade to 2.6.27.

Works fine here. intel 2100 wireless, Driver problem, Not dhcpcd.
You use either ndiswrapper or the kernel driver.
The wireless stack in 2.6.27 has under gone some so changes so there will be bugs.
If dhclient works, Stick with it.

I can confirm the bug, however in my case it was sufficient to downgrade dhcpcd.

I did a full system upgrade, which updated the kernel from 2.6.27.1-1 to 2.6.27.4-1. The dhcpcd version was already 4.0.2-1. dhcpcd started to fail with timeouts after the upgrade.

Downgrading to dhcpcd-3.2.1-1 fixed the problem and I'm still running with kernel 2.6.27.4-1.

This was on a Intel Gigabit 82541PI (NOT wireless!)

just compiled newest dhcpcd with ABS, and everything is working perfect...

can anyone confirm that just recompile dhcpcd is the solution, because then it's not a kernel bug at all.

Updating to dhcpcd 4.0.4 fixed the problem for me, too. (using the rt2500 driver)

can we close this then?

Maybe wait until dhcpcd 4.0.4 moves out of testing to close this, so that people who don't use testing can refer / add to it if necessary? I haven't got dhcpcd 4.0.3/4.0.4 to work with kernel 2.6.27.5, but I'm using a custom built kernel and still need to check if some options I turned on for 2.6.27.5 are causing the problem.

This problem seems to be chipset dependent. At work I have:
Broadcom Corporation NetXtreme BCM5705_2 Gigabit Ethernet (rev 03)
dhcpcd 4.0.3
kernel 2.6.27.5
--> no problem.

At home I have:
3COM 3CCFE574BT 10/100 PCMCIA

and lots of problems with different combintations of dhcpcd 3.2.1/4.0.3/4.0.4 and kernel 2.6.26/2.6.27.5.

Hmm, bad news, it doesn't work on my computer...I just did a few tests:
dhcpcd-3.2.1-1 + kernel26-2.6.27.5-1 = Working (old dhcp from core, kernel from core)
dhcpcd-4.0.3-1 + kernel26-2.6.27.5-1 = NOT working (dhcpcd from core, kernel from core)
dhcpcd-4.0.4-1 + kernel26-2.6.27.5-1 = NOT working (dhcpcd from testing, kernel from core)

Did a complete system upgrade of all packages afterwards, no difference :(

Went back to dhcpcd-3.2.1-1 and now it works fine again.

Still on Intel Gigabit 82541PI

If dhcpcd-3 works and dhcpcd-4 fails it's probably because of DUID usage.
dhcpcd-3 enabled DUID by default and stored it in /var/lib/dhcpcd
dhcpcd-4 does not enable DUID by default AND requires it in /etc/dhcpcd.duid in a slightly different format.

The Gentoo ebuild has code to move the DUID file from dhcpcd-3 to dhcpcd-4.
If dhcpcd-4 is built with COMPAT support (I don't know if Arch does or not) then dhcpcd-4 will enable DUID by default IF the DUID file exists.

The reason why it's now disabled by default is this - a lot of SOHO routers with DHCP servers rejected everything with DUID. Also, a lot of Windows DHCP server configurations rejected it also (but not by default).

I may not check back on this bug - I just track dhcpcd bugs randomly after a few too many glases of wine :)
If you feel it is a dhcpcd bug, then please open a ticket at http://roy.marples.name/projects/dhcpcd/newticket and attach wireshark traces of dhcpcd-3 (or any dhcp client) working and dhcpcd-4 failing and we'll work from there.

Thanks!

I just got my system working with latest kernel and latest dhcpcd from core....but only after a complete FTP-reinstall with the 2008.06-ftp-i686 iso and disabling an unused NIC in the BIOS.

Before I reinstalled my system I did a full system upgrade, which upgraded the system to kernel 2.6.27.7-1 and dhcpcd 4.0.4-1. This didn't solve the problem, still same issue.

In my system I have an Intel Gigabit 82541PI which previously has been mapped to eth0 with udev. I also have a 100mbit integrated NIC which previously has been mapped to eth1.

Since I don't use the integrated 100mbit NIC, I decided to disable this NIC in the BIOS before reinstalling to prevent setting up persistent naming in udev.

When the reinstall was completed, the problem was gone(!!!)...can this somehow be related to the udev mapping and the way dhcpcd look up network devices? If dhcpcd for some reason look up the wrong device, that would explain why I got DHCP-timeouts, since I didn't have a cable in the 100mbit NIC...

Does any of you with the same issue use persistent NIC naming in udev? If not, perhaps some syntax has changed in one of the config files related to dhcpcd or arch linux specific networking / startup scripts? That could also explain why my clean install works out-of-the-box.

dhcpcd looks up the device by its name (eth0, eth1, etc).
udev *can* change device names. I don't use Arch, but in Gentoo there are "Persistent Net Rules" which sometimes don't work exactly as planned. If Arch has the same feature, then a re-install would have wiped out the persistent rule mappings and started afresh.

Also, a user submitted a patch recently which fixed an issue where a flapping interface link would reset a timer.
Basically the driver said "Link status changed!" but a status query said "ehhh, no it hasn't". dhcpcd still reset the timer, but now it only resets when the link status has infact changed.
This fix is available in dhcpcd-4.0.7.

dhcpcd 4.0.7 is available in testing. Can someone who had problems please verify this release fixes the problem ?

I have kernel 2.6.27-ARCH and dhcpcd-4.0.7-1 lead to a timeout when I'm directly connected to my modem. (I have the following card: 3c900 10BaseT 3Com Corporation) and a cable modem (Arris)
When I'm behind a router (netgear), it works fine, and I get a connection.

This is the output when I get a timeout.

# dhcpcd -d eth0
eth0: dhcpcd 4.0.7 starting
eth0: hardware address = 00:10:4b:dc:f3:a1
eth0: executing `/usr/lib/dhcpcd/dhcpcd-run-hooks', reason PREINIT
eth0: broadcasting for a lease
eth0: sending DHCP_DISCOVER with xid 0x70be6c0c, next in 4.86 seconds
eth0: ignoring packet with xid 0x1b00eca9 as it's not ours (0x70be6c0c)
eth0: sending DHCP_DISCOVER with xid 0x70be6c0c, next in 8.07 seconds
eth0: ignoring packet with xid 0xcb7f0201 as it's not ours (0x70be6c0c)
eth0: ignoring packet with xid 0x1b00eca9 as it's not ours (0x70be6c0c)
eth0: ignoring packet with xid 0xcc7f0201 as it's not ours (0x70be6c0c)
eth0: ignoring packet with xid 0xbed10501 as it's not ours (0x70be6c0c)
eth0: ignoring packet with xid 0xbed10501 as it's not ours (0x70be6c0c)
eth0: sending DHCP_DISCOVER with xid 0x70be6c0c, next in 16.92 seconds
eth0: ignoring packet with xid 0xee27c8a3 as it's not ours (0x70be6c0c)
eth0: ignoring packet with xid 0xee27c8a3 as it's not ours (0x70be6c0c)
eth0: ignoring packet with xid 0xa061f37 as it's not ours (0x70be6c0c)
eth0: ignoring packet with xid 0x59cc4c05 as it's not ours (0x70be6c0c)
eth0: ignoring packet with xid 0x59cc4c05 as it's not ours (0x70be6c0c)
eth0: ignoring packet with xid 0x78b60201 as it's not ours (0x70be6c0c)
eth0: ignoring packet with xid 0x79b60201 as it's not ours (0x70be6c0c)
eth0: ignoring packet with xid 0x9d9de624 as it's not ours (0x70be6c0c)
eth0: ignoring packet with xid 0xd15fa5c5 as it's not ours (0x70be6c0c)
eth0: ignoring packet with xid 0xefd93e4d as it's not ours (0x70be6c0c)
eth0: ignoring packet with xid 0x30c42241 as it's not ours (0x70be6c0c)
eth0: ignoring packet with xid 0x30c42241 as it's not ours (0x70be6c0c)
eth0: sending DHCP_DISCOVER with xid 0x70be6c0c, next in 31.43 seconds
eth0: timed out
eth0: trying to use old lease in `/var/lib/dhcpcd/dhcpcd-eth0.lease'
eth0: probing for an IPV4LL address
eth0: checking 169.254.157.140 is available on attached networks
eth0: sending ARP probe (1 of 3), next in 1.87 seconds
eth0: sending ARP probe (2 of 3), next in 1.67 seconds
eth0: sending ARP probe (3 of 3), next in 2.00 seconds
eth0: using IPv4LL address 0.0.0.0
eth0: adding IP address 169.254.157.140/16
eth0: executing `/usr/lib/dhcpcd/dhcpcd-run-hooks', reason IPV4LL
eth0: forking to background

I had to switch back to dhcpcd-4.0.4-1 to get my internet working when I don't use a router.

The only thing that could have changed here is the default ClientID usage as from dhcpcd-4.0.5 upwards dhcpcd no longer send a ClientID by default, to match dhclient and the in-kernel DHCP client.

Try adding clientid to /etc/dhcpcd.conf
echo "clientid" >> /etc/dhcpcd.conf

If that fails, could you email me a wireshark trace from dhcpcd-4.0.4 and dhcpcd-4.0.7 so I can see why it's now failing for you.

Hello,

thanks, this solved the problem with dhcpcd-4.0.7-1.