# dhcpcd fails to configure eth0 [SOLVED]

## fornix

I am installing gentoo using minimal CD.

I compiled my kernel and when booting into my new system, I get this error and dhcpcd doesnt assign IP address for my NIC.

When the pc boots, i get the following message a lot of times

```

eth0: dhcpcd 4.0.13 starting

eth0: waiting for carrier

eth0: carrier acquired

eth0: broadcasting for a lease

eth0: offered 192.168.66.102 from 192.168.66.1

eth0: checking 192.168.66.102 is available on attached networks

eth0: NAK: (null) from 192.168.66.1

eth0: broadcasting for a lease

eth0: offered 192.168.66.102 from 192.168.66.1

eth0: checking 192.168.66.102 is available on attached networks

eth0: NAK: (null) from 192.168.66.1

.....in a loop

```

My /etc/conf.d/net contains the following string

```
config_eth0=( "dhcp" )

```

And I have to manually assign the ip address 192.168.66.102 using ifconfig and add a default gateway using route and add my router ip in /etc/resolv.conf for my internet to work.

In my router, I have reserved 192.168.66.102 ip address for my mac address. Maybe this is causing the problem. 

My previous gentoo system had no problems with this. Also, i have Ubuntu and Windows on the same computer working fine with this router.

When running dhcpcd eth0 -d, I get the following output

```

eth0: dhcpcd 4.0.13 starting

eth0: hardware address = 00:1a:92:81:56:dc

eth0: executing '/lib/dhcpcd/dhcpcd-run-hooks', reason PREINIT

eth0: waiting for carrier

eth0: carrier acquired

eth0: broadcasting for a lease

eth0: sending DHCP_DISCOVER with xid 0x5ec99479, next in 3.65 seconds

eth0: offered 192.168.66.102 from 192.168.66.1

eth0: sending DHCP_REQUEST with xid 0x5ec99479, next in 3.32 seconds

eth0: acknowledged 192.168.66.102 from 192.168.66.1

eth0: checking 192.168.66.102 is available on attached networks

eth0: sending ARP probe (1 of 3), next in 1.66 seconds

eth0: NAK: (null) from 192.168.66.1

eth0: broadcasting for a lease... and it continues...

```

----------

## VinzC

Are you using dhcpcd-4* ? If yes, try downgrading to version 3* and retry.

----------

## fornix

 *VinzC wrote:*   

> Are you using dhcpcd-4* ? If yes, try downgrading to version 3* and retry.

 

Yes I am using dhcpcd-4.0.13

Another interesting thing which I found out was that when I disabled the IP address reservation for my mac in the router, dhcpcd works find and now it gets the ip 192.168.66.100.

I am assuming that when the ip address 192.168.66.102 is fixed for my PC in the router settings, the dhcp server sends out something which dhcpcd doesnt expect. 

Will try downgrading it.

----------

## VinzC

Actually dhcpcd-4* complies with an RFC (forgot which one) where the host name is sent in a certain format, FQDNS, IIRC. It sometimes doesn't work with DHCP servers that do not comply with that RFC, unsurprisingly including Windows DHCP servers. But there may as well be more.

----------

## UberLord

If /etc/dhcpcd.duid exists, remove it and then retry.

But it's kinda odd that your DHCP server is allocating an address and then NAKing it. What DHCP server are you using?

----------

## fornix

 *UberLord wrote:*   

> If /etc/dhcpcd.duid exists, remove it and then retry.
> 
> But it's kinda odd that your DHCP server is allocating an address and then NAKing it. What DHCP server are you using?

 

/etc/dhcpcd.duid does not exist on my system. I think the DHCP server is sending a NAK in response to the ARP request.

Can I disable this "sending ARP request" part to check if IP is available on other networks.

And I could not find an ebuild for any version less than 4 in /usr/portage/net-misc/dhcpcd/

```
fornix@nanosoft ~ $ ls /usr/portage/net-misc/dhcpcd/      

ChangeLog  dhcpcd-4.0.13.ebuild  dhcpcd-5.0.4.ebuild  metadata.xml

Manifest   dhcpcd-4.0.7.ebuild   files

```

The DHCP server is on a router DLink DIR 300. It uses firmware called tomizone http://www.tomizone.com/downloads/firmware I downloaded the source code of this firmware from here http://media.tomizone.com/firmware/openwrt-tomizone-1.4.1.tar.gz

I was unable to find out the version of the server. It uses openwrt internally. Next I am going to sniff packets and then run dhcpcd eth0 and check. I will post the captured packets here.

----------

## UberLord

 *fornix wrote:*   

> I think the DHCP server is sending a NAK in response to the ARP request.
> 
> Can I disable this "sending ARP request" part to check if IP is available on other networks.

 

Well, it's very silly if it does as ARP is not part of the DHCP spec - it's just recommended to ensure that the DHCP server is allocating a free address.

You can disable it in /etc/dhcpcd.conf with a single line of "noarp" 

 *Quote:*   

> 
> 
> The DHCP server is on a router DLink DIR 300. It uses firmware called tomizone http://www.tomizone.com/downloads/firmware I downloaded the source code of this firmware from here http://media.tomizone.com/firmware/openwrt-tomizone-1.4.1.tar.gz
> 
> I was unable to find out the version of the server. It uses openwrt internally. Next I am going to sniff packets and then run dhcpcd eth0 and check. I will post the captured packets here.

 

The chance are that you're using the dnsmasq DHCP server then. Can you find out which version it's running? IE, do you have console access to the router?

----------

## fornix

I sniffed the packets using wireshark after typing in "# dhcpcd eth0". The wireshark pcap file has been uploaded at http://ifile.it/rvpl73b

I found out one very interesting thing but first let me explain what is happening currently.

1. My PC (Current IP 0.0.0.0) sends out DHCP Discover packet

2. Router sends back DHCP offer to 192.168.66.102

3. My PC sends out DHCP Request

4. Router sends out an ACK which contains my PC Mac id as destination Mac and destination ip address 192.168.66.102

5. Router sends out a NACK which contains mac id ff:ff:ff:ff:ff:ff

Now my dhcpcd client fails to pick up the step 4 packet. (Maybe because it looks at destination IP address. Still my ip is 0.0.0.0)

***Next, the very interesting thing***

I did the following thing next.

1. I killed dhcpcd client.

2. I did a "# ifconfig eth0 192.168.66.102" to manually set my ip address as the one which the router sends in step 2 above

3. Next, i typed in "# dhcpcd -d eth0"

```
nanosoft fornix # dhcpcd -d eth0

eth0: dhcpcd 4.0.13 starting

eth0: hardware address = 00:1a:92:81:56:dc

eth0: executing `/lib/dhcpcd/dhcpcd-run-hooks', reason PREINIT

eth0: broadcasting for a lease

eth0: sending DHCP_DISCOVER with xid 0x34b05d26, next in 3.35 seconds

eth0: offered 192.168.66.102 from 192.168.66.1

eth0: sending DHCP_REQUEST with xid 0x34b05d26, next in 3.75 seconds

eth0: acknowledged 192.168.66.102 from 192.168.66.1

eth0: leased 192.168.66.102 for infinity

eth0: adding IP address 192.168.66.102/24

eth0: adding route to 0.0.0.0/0 via 192.168.66.1

eth0: executing `/lib/dhcpcd/dhcpcd-run-hooks', reason BOUND

eth0: forking to background

```

and voila! dhcpcd works.

I sniffed packets this time too and found out that even this time, the router sends an ACK to my pc mac id followed by a NAK to mac id ff:ff:ff:ff:ff:ff

But this time it correctly picked up the ACK and ignored the NAK

All this was done with reservation of ip address 192.168.66.102 for my pc mac address in router settings.

My final step would be to disable this reservation and sniff packets. (In this case dhcpcd always works) I will upload the packets once i sniff.

----------

## fornix

 *UberLord wrote:*   

> 
> 
> The chance are that you're using the dnsmasq DHCP server then. Can you find out which version it's running? IE, do you have console access to the router?

 

The worst part is that the router does not support ssh. I know its lame and I am even thinking of changing the firmware due to that. Only interface is an http one.

----------

## UberLord

 *fornix wrote:*   

> I sniffed the packets using wireshark after typing in "# dhcpcd eth0". The wireshark pcap file has been uploaded at http://ifile.it/rvpl73b

 

Could you email it to roy@marples.name please? I don't want to sign up for a download service

 *Quote:*   

> 
> 
> I found out one very interesting thing but first let me explain what is happening currently.
> 
> 1. My PC (Current IP 0.0.0.0) sends out DHCP Discover packet
> ...

 

It "ignored" the NAK because the process had completed. ARP check takes enough time for dhcpcd to spot the NAK during configuration. This implies that it's not ARP at fault and you're just working around the real issue. However, you can skip the ARP check as shown above as another work around.

----------

## fornix

 *UberLord wrote:*   

> 
> 
> The chance are that you're using the dnsmasq DHCP server then. Can you find out which version it's running? IE, do you have console access to the router?

 

Yes indeed, from the source code of my firmware, it does seem that dnsmasq is the server being used. i came across /openwrt-wr-tomizone/openwrt-wr/package/dnsmasq/Makefile

```
PKG_NAME:=dnsmasq

PKG_VERSION:=2.35

PKG_RELEASE:=1

PKG_MD5SUM:=57b8643dc394cf2fbd1bced64536c6df
```

The version is 2.35

 *UberLord wrote:*   

> 
> 
> Could you email it to roy@marples.name please? I don't want to sign up for a download service
> 
> 

 

No sign up is required for downloading. Just have to click on Request Download ticket and Download.

Anyways, i am sending it at the email id too.

----------

## UberLord

This is a dnsmasq error from what I can see, and I'm also pretty sure that it's been fixed as the dnsmasq version you're running is quite old.

However, you are sending a client id which is no longer the default. Please remove any options regarding client id from /etc/dhcpcd.conf or any equivalent dhcpcd options in /etc/conf.d/net. Pastebin those files if unsure.

 *Quote:*   

> No sign up is required for downloading. Just have to click on Request Download ticket and Download.
> 
> Anyways, i am sending it at the email id too.

 

Well, complain to the service that the download links look like ads for other services. On the page I had, two big download images were for downloading other products to make my pc faster, so any other download like was lost in the noise.

----------

## fornix

 *UberLord wrote:*   

> This is a dnsmasq error from what I can see, and I'm also pretty sure that it's been fixed as the dnsmasq version you're running is quite old.

 

Quite possible. From my analysis, whenever I tell dnsmasq that assign IP address 192.168.66.102 for mac address 00:1a:92:81:56:dc, it sends an ack to the pc with mac address 00:1a:92:81:56:dc followed by a Broadcast NAK.

Proof: http://ifile.it/rvpl73b (Same link as in my previous post)

Now, when I tell dnsmasq that no such reservation is required, it sends an ack and does not send a broadcast NAK as in the previous case.

Proof: 

```
nanosoft fornix # dhcpcd -d eth0

eth0: dhcpcd 4.0.13 starting

eth0: hardware address = 00:1a:92:81:56:dc

eth0: executing `/lib/dhcpcd/dhcpcd-run-hooks', reason PREINIT

eth0: broadcasting for a lease

eth0: sending DHCP_DISCOVER with xid 0x39bf9d5e, next in 3.88 seconds

eth0: offered 192.168.66.100 from 192.168.66.1

eth0: sending DHCP_REQUEST with xid 0x39bf9d5e, next in 3.99 seconds

eth0: acknowledged 192.168.66.100 from 192.168.66.1

eth0: checking 192.168.66.100 is available on attached networks

eth0: sending ARP probe (1 of 3), next in 1.20 seconds

eth0: sending ARP probe (2 of 3), next in 1.07 seconds

eth0: sending ARP probe (3 of 3), next in 2.00 seconds

eth0: leased 192.168.66.100 for 604800 seconds

eth0: adding IP address 192.168.66.100/24

eth0: adding route to 0.0.0.0/0 via 192.168.66.1

eth0: executing `/lib/dhcpcd/dhcpcd-run-hooks', reason BOUND

eth0: forking to background

```

Packet captured: http://ifile.it/s3ezjrp  (New packets captured. And beware of ADS!   :Very Happy:  )

When i add noarp in /etc/dhcpcd.conf although a NAK is sent, it is ignored by dhcpcd (When reservation is done). As you said, it does not wait if arp is disabled.

So we can come to the following deductions:

1. DHCP Server sends an unnecessary NAK

2. DHCP client considers any NAK as hi priority (even if it has previously received an ACK)

Hence problem can be solved in two ways: 

1. Prevent server from sending unnecessary broadcast NAK (This is difficult for me as i am already using latest router firmware which uses old version dhcp server)

2. Make the client ignore any NAKs after an ACK.

Workarounds for the problem:

1. Add line noarp in /etc/dhcpcd.conf

2. Manually assign the IP before calling dhcpcd (Very weird workaround and can be ignored)

 *UberLord wrote:*   

> 
> 
> However, you are sending a client id which is no longer the default. Please remove any options regarding client id from /etc/dhcpcd.conf or any equivalent dhcpcd options in /etc/conf.d/net. Pastebin those files if unsure.
> 
> 

 

My /etc/dhcpcd.conf minus the comments:

```
nanosoft fornix # cat /etc/dhcpcd.conf | grep -v \#

option domain_name_servers, domain_name, domain_search, host_name

option ntp_servers

```

My /etc/conf.d/net minus the comments:

```
nanosoft fornix # cat /etc/conf.d/net | grep -v \#

config_eth0=( "dhcp" )

```

Should I add solved to the topic as I can add a noarp in /etc/dhcpcd.conf and forget about the issue.

But I do believe that if the DHCP client ignores this unnecessary packet after an ACK, the DHCP client would be more sturdy.

I am leaving this topic as open if the developer wants me to test any patch or something as I can simulate this problem easily.

Thanks.

----------

## fornix

I changed my router firmware to dd-wrt from the factory firmware. So this problem is solved for me.

----------

## UberLord

Thanks for posting back and telling us where the issue was  :Smile: 

----------

## fornix

 *UberLord wrote:*   

> Thanks for posting back and telling us where the issue was 

 

Not everyone would want to risk changing the router firmware from the factory firmware and void their warranty. People would usually change the dhcp client for such trivial error even though the source of the problem wasn't the client. I still strongly feel the client should be able to handle this. Nevermind, this topic should help those poor folks with dlink-300 router series and facing the same problem.

----------

## UberLord

I can't really argue with that.

Could you open a ticket at http://roy.marples.name/projects/dhcpcd/newticket so I don't forget about it? I should have time to work on dhcpcd next week maybe.

----------

## UberLord

dhcpcd-5.0.6 will now handle this

http://roy.marples.name/projects/dhcpcd/changeset/f95ed95172e3648a214b74a01cc32ef32b270431

I may see if I can fix dhcpcd-4 in a similar way.

----------

