# slow dhcpcd start (getting slower and slower)

## nein

Hi,

 I just upgraded dhcpcd to the latest stable version (dhcpcd-2.0.0) and now it takes 30 seconds to get an IP. I already noticed an slowdown in the last baselayout upgrade. Before the baselayout upgrade I had:

dhcpcd_eth0="-t 7"

in /etc/conf.d/net. After the baselayout upgrade (now I have  baselayout-1.11.13-r1) I had to set the timeout to 17 secs and now, after the dhcpcd upgrade I need a 40 secs timeout.

What is causing these increasing slowdown in the dhcp ip address negotiation ?

Thanks in advance

----------

## hickmott

I'm seeing this, too. I upgraded to dhcpcd-1.3.22_p4-r5 in mid July, and it started taking about 30 seconds to connect - slow, but not actually a problem. This morning it brought in dhcpcd-2.0.0, and it's up over 2 minutes.

The NIC's a 3c59x-based PCI card that the phone company gave me when I got DSL. Kernel version's 2.6.12-gentoo-r9.

--Andy Hickmott

----------

## Massis

Same here, but I think it is a kernel issue (or maybe it's the combination kernel-baselayout-dhcpcd?).  If I use one of my older kernels (2.6.7 gentoo sources) , dhcp is fast (around 2 seconds).  But if i use the latest (2.6.12-r9 gentoo sources) is takes about a minute...  Any specialist having a clue?   :Wink: 

----------

## Fromeo

I'm getting the same problem with one machine.  I was thinking about it, and somehow the "two minute" number rung a bell in my head, and I remembered post on the OpenBSD FAQ a long time ago:

http://www.openbsd.org/faq/faq8.html#RevDNS

I tried running tcpdump on the dhcp server to see what packets were going where, and it looks like the client machine just hangs out for a little while before suddenly squirting off the packets, getting an IP, and continuing on.  Could there be some kind of reverse DNS lookup that dhcpcd is trying to do before it gets an address?  It does sound nutsy on the face of it (how could it do a DNS lookup before it knows where DNS is?), but the timing just seemed like it fit.

----------

## UberLord

There are 3 other dhcp clients you can use you know.

I use pump myself

----------

## nein

I have just tried pump and I think it took even longer.

I have checked my logs and I see these entries during dhcp negotiation:

```

Sep  5 11:31:44 kernel: b44: eth0: Link is up at 100 Mbps, full duplex.

Sep  5 11:31:44 kernel: b44: eth0: Flow control is on for TX and on for RX.

Sep  5 11:31:54 kernel: NETDEV WATCHDOG: eth0: transmit timed out

Sep  5 11:31:54 kernel: b44: eth0: Link is down.

Sep  5 11:31:57 kernel: b44: eth0: Link is up at 100 Mbps, full duplex.

Sep  5 11:31:57 kernel: b44: eth0: Flow control is on for TX and on for RX.

```

I can also see that the light on the network switch corresponding to my conection turnes off and then back on.

I can also confirm that with older kernels the process is faster but I think there are also issues related to dhcp.

----------

## Massis

Same here, i tried udhcp and it takes as long as dhcpcd did...

@UberLord: what are the interesting places we can look for messages about this?

----------

## UberLord

just kernel logs afaik

It may also be a dhcp server issue - I use dnsmasq and it's fast

----------

## nein

my dhcp server is a gentoo box using the stable dhcp server (dhcp-3.0.1-r1)

----------

## Pajarico

Nothing to add, I'm just getting the same (2.0.0 too).

----------

## Pajarico

This worked for me.

 *<3 wrote:*   

> I was having the same problem. It would sometimes take almost 5 mins before it would get an ip address. Although i am not behind a firewall, as I had one of my two  ethernet cards connected directly to my cable modem, Adding this line to /etc/config.d/net solved the problem.
> 
> ```
> 
> dhcpcd_eth0="-t 3" 
> ...

 

----------

## hickmott

The "-t 3" option doesn't work for me. I have to set the timeout up to "-t 300" or I don't get a connection at all.

----------

## Pajarico

Actually, it didn't work for me either. I thought it did because i already had a connection. 

Let me explain, if i do:

```
dhcpcd

killall dhcpcd

dhcpcd
```

... the first time it takes about 30 seconds, not matter the options i use, but the second time is instantaneous. I was fooled by this, it seems like when i killed dhcpcd it really didn't kill the connection, just the client.

----------

## Braempje

I'm having this problem too, but only with a broadcom using the b44 driver...

----------

## demitrix

ive got the same problem here too   :Crying or Very sad: 

----------

## roderick

I also have the same issue. Also using a broadcom.

----------

## hickmott

I'm using a Linksys (not wireless). It's been working perfectly for three years, and is still working perfectly for my wife's machine. I'm pretty sure the  problem (as I'm seeing it) is not with the DHCP server.

----------

## Braempje

 *hickmott wrote:*   

> I'm using a Linksys (not wireless). It's been working perfectly for three years, and is still working perfectly for my wife's machine. I'm pretty sure the  problem (as I'm seeing it) is not with the DHCP server.

 

I'm seeing the same behaviour. Connecting wireless to a Linksys works faster then over a wire, using the broadcom card...

----------

## nein

I suspect the whole problem had to do with my wifi card. I did not have any setting for the wifi card and now that I have configured it, the normal net card starts faster.

----------

## hickmott

This seems to have been fixed with kernel 2.6.14-r2 and/or gcc-3.4.

----------

