# Dhcpcd 4.x troubles

## Sperlock

With dhcpcd 4.0.2 on my desktop, I get the following upon boot up:

```

eth0: broadcasting for a lease

eth0: offered 192.168.123.200 from 192.168.123.123

eth0: checking 192.168.123.200 is available on attached networks

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.22.162 is available on attached networks

eth0: using IPv4LL address 169.254.22.162

```

I am not sure where it is getting 192.168.123.123 - that is not the address of my router.  I cannot get to the Internet because of this.

My /etc/conf.d/net is:

```

dns_domain_lo="homenetwork"

config_eth0=( "dhcp" )

dhcp_eth0=""

```

My laptop has this configuration and grabs an IP address from my router and works fine (also using 4.0.2).

I had to go back down to dhcpcd 3.2.3 and my desktop gets a proper IP address and connects to the Internet just fine.

How in the world do I fix things so they work with dhcpcd 4.x?

----------

## UberLord

There is a recently fixed bug regarding ARP and a flapping interface link.

You can find the patch here.

http://roy.marples.name/projects/dhcpcd/changeset/1103/branches/dhcpcd-4.0/client.c

I should be releasing a new dhcpcd version with that fix in over the next few days.

In the meantime, you can disable ARP checking by adding dhcpcd_eth0="-A" to conf.d/net

But I'd appreciate it if you can test the patch as that is the preferred fix!

----------

## Sperlock

What is the recommended way to apply the patch?  Is there anything I need to be cautious of as a result of applying this patch, such as portage having a problem because a file does not match the standard file for that version, or ?

I did try adding dhcpcd_eth0="-A" to conf.d/net (as I saw reference to a very similar problem in another post), but it did not make a difference.

I'm also willing to test out the new dhcpcd version when you release it - just let me know which version to look out for!

Thanks!

----------

## UberLord

 *Sperlock wrote:*   

> What is the recommended way to apply the patch?  Is there anything I need to be cautious of as a result of applying this patch, such as portage having a problem because a file does not match the standard file for that version, or ?

 

Alter the ebuild so that it looks like so

```

src_unpack() {

    unpack ${A}

    cd "${S}"

    epatch /tmp/dhcpcd.patch
```

It's the last line you add - ensure that you save the patch as /tmp/dhcpcd.patch

 *Quote:*   

> I did try adding dhcpcd_eth0="-A" to conf.d/net (as I saw reference to a very similar problem in another post), but it did not make a difference.

 

My bad, should be -K

 *Quote:*   

> I'm also willing to test out the new dhcpcd version when you release it - just let me know which version to look out for!
> 
> Thanks!

 

What you look for is the next version working  :Smile: 

----------

## Sperlock

Ok, I altered the ebuild for dhcpcd-4.0.2, but emerge complains with this:

```

Calculating dependencies -!!! Digest verification failed:

!!! /usr/portage/net-misc/dhcpcd/dhcpcd-4.0.2.ebuild

!!! Reason: Filesize does not match recorded size

!!! Got: 2324

!!! Expected: 2298

!!! All ebuilds that could satisfy "=net-misc/dhcpcd-4.0.2" have been masked.

!!! One of the following masked packages is required to complete your request:

- net-misc/dhcpcd-4.0.2 (masked by: corruption)

```

It will do this even when trying to ACCEPT_KEYWORDS="~x86".

What is the trick from here?

----------

## tarpman

```
ebuild /usr/portage/net-misc/dhcpcd/dhcpcd-4.0.2.ebuild digest
```

----------

## UberLord

Made it a bit easier  :Smile: 

dhcpcd-4.0.7 is now in portage with the patch.

Enjoy! And let me know if it works  :Wink: 

----------

## Sperlock

No such luck.  dhcpcd-4.0.7 made no difference for me.  Neither did adding -K for dhcpcd-4.0.2.  :Sad: 

----------

## UberLord

Well, you didn't post any timings with your initial log, so it was just a guess  :Smile: 

Here's another one - clientID!

Remove the duid keyword from /etc/dhcpcd.conf if it exists and delete /etc/dhcpcd.duid if it exists.

Then restart dhcpcd!

----------

## Sperlock

Timings as in how long an IP is leased for?

/etc/dhcpcd.conf does not exist on my system, though /etc/dhcpcd.duid does.  Do I still go ahead and remove that?  Do I need to worry about the one in /var/lib/dhcpcd/?

----------

## UberLord

 *Sperlock wrote:*   

> Timings as in how long an IP is leased for?

 

More like how long dhcpcd waits on each step TO get the lease.

You can find this in syslog.

 *Quote:*   

> /etc/dhcpcd.conf does not exist on my system, though /etc/dhcpcd.duid does.  Do I still go ahead and remove that?  Do I need to worry about the one in /var/lib/dhcpcd/?

 

/etc/dhcpcd.conf needs to exist, otherwise you may get a lease but things won't exactly work like DNS resolution.

dhcpcd-4 ebuilds should create it. You can find the default here:- http://roy.marples.name/projects/dhcpcd/browser/branches/dhcpcd-4.0/dhcpcd.conf

Saying that, it could get removed if you never changed it AND downgraded back to dhcpcd-3 and checked.

Yes, you should erase /etc/dhcpcd.duid.

You should NOT erase the one in  /var/lib/dhcpcd - that is for dhcpcd-3 which you say is working.

----------

## Sperlock

Okay, dhcpcd.conf was there when I reinstalled dhcpcd-4.0.2.  I removed dhcpcd.duid and everything works now.  :Smile:   Thanks!

I'll see if I can get this thread marked as SOLVED.

----------

## UberLord

Cool! Once satisfied that dhcpcd-4 is working fine then remove the old /var/lib/dhcpcd stuff.

----------

## VinzC

Hello all.

I've run into troubles recently with OpenRC-0.3* (not sure it's related to OpenRC though) and dhcpcd-4*. I've had to downgrade to dhcpcd-3* otherwise connectivity was lost upon renewing the lease with my ISP. I've got a few other places where I use dhcpcd-4* and it works fine (especially with dnsmasq).

Let's recap the trouble with my ISP. With dhcpcd-4* the machine boots fine and gets a lease from my ISP (teledisnet.be aka voo.be). After probably eight hours or when the lease is renewed, connectivity is lost, i.e. a ping towards my ISP main router doesn't work and times-out. Pinging with any host name on the Internet ends up in a name resolution failure.

I must restart my WAN interface init script to temporarily fix the problem... until the next lease renewal. Currently it works with dhcpcd-3.2.3. I think the problem started with >=dhcpcd-4.0.2 but I'm not sure.

I haven't waited long enough to be 100% certain the problem arises when renewing the lease though. It's only a deduction. I also have a firewall, which allows incoming DHCP packets:

```
iptables -A INPUT -i <WANIF> -p udp -m udp --sport 67 --dport 68 -j ACCEPT
```

It has always worked until now.

----------

## UberLord

What dhcpcd version are you using? 4.0.7 is the latest.

If 4.0.7 still fails, could you supply tcp dumps of the DHCP renewal failing with dhcpcd-4 and working with dhcpcd-3?

----------

## VinzC

 *UberLord wrote:*   

> What dhcpcd version are you using? 4.0.7 is the latest.
> 
> If 4.0.7 still fails, could you supply tcp dumps of the DHCP renewal failing with dhcpcd-4 and working with dhcpcd-3?

 

I've checked versions 4.0.2 and 4.0.7. Now I'm using 3.2.3 as I said. I think it was working with dhcpcd-4.0.1-r1.

Now since it can take ages to wait for a dump -- I'm not always sat at my computer when it renews its lease, you know  :Wink:  -- is there a way to trigger a dump shortly before or right when dhcpcd renews its lease? (I'll probably not fill a dump for 8 hours or more.)

----------

## UberLord

You can trigger a rebind using "dhcpcd -n eth0". This is not the same as a renew.

To trigger a renew faster, try requesting a short lease time using the -l option.

----------

## VinzC

Update: running dhcpcd -n eth1 also fixes the problem. I really have to wait until the lease is renewed by itself  :Sad:  . Will use the -l option.

Last Update: Problem solved!

My bad (probably  :Wink:  ). My firewall was blocking outgoing UDP traffic from port 68 to port 67 on the DHCP server -- thanks to option -l I've been able to see it in real time!

```
Dec 15 19:06:16 athena flt-out: IN= OUT=eth1 SRC=x.y.z.23 DST=u.v.w.218 LEN=342 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=68 DPT=67 LEN=322 UID=0 GID=0
```

I've updated the rules of my firewall and now dhcpcd renews its lease properly.

I wonder how it worked with dhcpcd-3*...  :Idea:  Did dhcpcd-3* keep the last IP even if the lease was not renewed?

----------

## UberLord

dhcpcd-3 renewed via broadcast, which is incorrect per the RFCs and only worked with some DHCP servers.

dhcpcd-4 renews via IP which is correct per the RFCs, works with all servers but does rely on a working firewall.

----------

## XenoTerraCide

I'm having timeout issues on 4.07 intermittent trying to troubleshoot. any recommendations? thinking of taking a sniffer to it.. but tcpdump seems to die on interface restart. other suggestions welcome.

----------

## UberLord

You can always try dhcpcd-4.99.x as that has a new state engine.

----------

## XenoTerraCide

you say it depends on a working firewall... my firewall rules are as follows (pseudocode) (on machine with dhcpcd)

policy input drop

invalid drop

related,established accept

-i lo accept

policy output accept.

do I need to make any additional allowances inbound? 

also ... you have any idea about this? perhaps related?

https://forums.gentoo.org/viewtopic-t-689636.html

----------

## UberLord

 *XenoTerraCide wrote:*   

> you say it depends on a working firewall... my firewall rules are as follows (pseudocode) (on machine with dhcpcd)
> 
> policy input drop
> 
> invalid drop
> ...

 

Should work, but timing issues do not depend on firewall.

Only lease renewal does.

 *Quote:*   

> do I need to make any additional allowances inbound? 

 

Future versions of dhcpcd may allow for the DHCP server to force a lease renew which means you'll have to have UDP bootpc port open all the time. Although a stateful firewall may remember this (I've not tested)

 *Quote:*   

> also ... you have any idea about this? perhaps related?
> 
> https://forums.gentoo.org/viewtopic-t-689636.html

 

It's not related to this topic.

----------

## XenoTerraCide

counters show 19 packets on 67 and 5 on 68... however they didn't increase on network reload... possibly other machines on the network that use broadcast...

----------

