# dhcpcd times out on first attempt. [WORKAROUND]

## gunther222

I have two different systems with the same behavior...

Both time out on their first dhcpcd attempt at boot.

Both have Realtek 8169 biult in adapters.

lspci ->

03:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 03)

```

[    1.446319] r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded

[    1.448431] r8169 0000:03:00.0: PCI INT A -> GSI 18 (level, low) -> IRQ 18

[    1.450567] r8169 0000:03:00.0: setting latency timer to 64

[    1.450608] r8169 0000:03:00.0: irq 44 for MSI/MSI-X

[    1.450852] r8169 0000:03:00.0: eth0: RTL8168d/8111d at 0xffffc900121a2000, 48:5b:39:ac:0b:1b, XID 083000c0 IRQ 44

[    7.841324] r8169 0000:03:00.0: eth0: unable to apply firmware patch

[    7.843135] r8169 0000:03:00.0: eth0: link down

[    7.843142] r8169 0000:03:00.0: eth0: link down

[   10.223831] r8169 0000:03:00.0: eth0: link up

```

Either restarting net.eth0 or running dhcpcd by hand work fine on the second attempt.

The first system is on baselayout 2 and has had all the configs dispatched

The second system was just freshly installed this morning and is therefor already on layout 2 and behaves the same way.

```

brontosaurus ~ # ethtool eth0

Settings for eth0:

        Supported ports: [ TP MII ]

        Supported link modes:   10baseT/Half 10baseT/Full

                                100baseT/Half 100baseT/Full

                                1000baseT/Half 1000baseT/Full

        Supports auto-negotiation: Yes

        Advertised link modes:  10baseT/Half 10baseT/Full

                                100baseT/Half 100baseT/Full

                                1000baseT/Half 1000baseT/Full

        Advertised pause frame use: No

        Advertised auto-negotiation: Yes

        Link partner advertised link modes:  10baseT/Half 10baseT/Full

                                             100baseT/Half 100baseT/Full

                                             1000baseT/Full

        Link partner advertised pause frame use: No

        Link partner advertised auto-negotiation: Yes

        Speed: 1000Mb/s

        Duplex: Full

        Port: MII

        PHYAD: 0

        Transceiver: internal

        Auto-negotiation: on

        Supports Wake-on: pumbg

        Wake-on: g

        Current message level: 0x00000033 (51)

                               drv probe ifdown ifup

        Link detected: yes

```

I'm running a recent version of dhcpcd on both boxes.

```

[I] net-misc/dhcpcd

     Available versions:  5.2.12 {elibc_glibc +zeroconf}

     Installed versions:  5.2.12(09:45:38 06/14/11)(elibc_glibc zeroconf)

     Homepage:            http://roy.marples.name/projects/dhcpcd/

     Description:         A fully featured, yet light weight RFC2131 compliant DHCP client

```

I thought I saw a thread about a problem with the realtek drivers the more recent kernels that have been causing these types of problems, but have not been able to locate it again.Last edited by gunther222 on Sun Jul 03, 2011 8:55 am; edited 1 time in total

----------

## bjlockie

I have an older but similar card that works fine.

lspci->

01:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 01)

 *Quote:*   

> r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded
> 
> ACPI: PCI Interrupt Link [LNEB] enabled at IRQ 19
> 
> r8169 0000:01:00.0: PCI INT A -> Link[LNEB] -> GSI 19 (level, low) -> IRQ 19
> ...

 

Mine doesn't try to apply a firmware patch.

How did you display  *Quote:*   

> 
> 
> [I] net-misc/dhcpcd

 

[ebuild   R    ] net-misc/dhcpcd-5.2.12  USE="zeroconf" 0 kB

What is elibc_glibc?

----------

## Hu

 *bjlockie wrote:*   

> How did you display  *Quote:*   
> 
> [I] net-misc/dhcpcd 
> 
> [ebuild   R    ] net-misc/dhcpcd-5.2.12  USE="zeroconf" 0 kB
> ...

 That is output from eix, part of app-portage/eix.  The flag elibc_glibc is used when a package needs special behavior for use on glibc based systems vs. others, such as uClibc.

----------

## gunther222

 *Hu wrote:*   

>  *bjlockie wrote:*   How did you display  *Quote:*   
> 
> [I] net-misc/dhcpcd 
> 
> [ebuild   R    ] net-misc/dhcpcd-5.2.12  USE="zeroconf" 0 kB
> ...

 

Hu nailed it right on the head, entirely correct.

----------

## gunther222

There must be a way to modify net.eth0 to bounce the card once before handing it off to dhcpcd, even if we can't find the basic problem with the driver...

Or a way to trace the individual packets being exchanged at start up...

Nothing has changed, this still still fails on both machines.

----------

## PoisonRO

Hy,

Any info on this ? I've got the same behavior.

Cheers,

Dan.

----------

## bjlockie

 *PoisonRO wrote:*   

> Hy,
> 
> Any info on this ? I've got the same behavior.
> 
> Cheers,
> ...

 

Do you use elibc_glibc too?

----------

## chiefbag

Why don't you just modify the dhcpd init script to add a restart of net.eth0 at the end of the script as the dhcpd init will have the need net directive in its own script.

This would be a quick fix for your issue if the modules are a bit flaky.

----------

## gunther222

 *chiefbag wrote:*   

> Why don't you just modify the dhcpd init script to add a restart of net.eth0 at the end of the script as the dhcpd init will have the need net directive in its own script.
> 
> This would be a quick fix for your issue if the modules are a bit flaky.

 

Because then you will still be left without an address on the interface since dhcpd will never have been re-run to get one.

----------

## chiefbag

Put the restart at the start of the dhcpd script instead.

----------

## gunther222

 *chiefbag wrote:*   

> Put the restart at the start of the dhcpd script instead.

 

I looked into the /etc/init.d/dhcpcd script, but I don't understand how it can even work in the first place, let alone how to modify it to do that.

Still need a viable solution.

----------

## gunther222

I spent the evening digging into the problem further and determined that the root of the problem is that there appears to be a problem with the r8169 driver which causes the interface to be unresponsive for almost 30 seconds after going from a DOWN state to an UP state.

I made a dhcpcd hook script that exercises the interface for 30 second with arping on any CARRIER transition before moving on to trying to get an address. With this modification in place the boxes I have have gotten a lease on the first attempt every time.

Here's the work around...

```

goldrush ~ # cd /lib64/dhcpcd/dhcpcd-hooks/

goldrush dhcpcd-hooks # touch 05-bump 

goldrush dhcpcd-hooks # nano -w 05-bump 

```

place the following in the 05-bump script...

```

# Just echo our DHCP options we have

if [ "$reason" = "CARRIER" ]; then

        set | grep "^\(interface\|metric\|pid\|reason\|skip_hooks\)=" | sort

        set | grep "^\(new_\|old_\)" | sort

        /sbin/arping -D -w 30 -I $interface 169.254.220.1

fi

```

----------

## jkomar

Thanks for the workaround. I have a board with a couple of Intel 82574L NICs on it (use the e1000e kernel module) which exhibit the same issue. Your workaround saved me a lot of headaches.

Jason

----------

## gunther222

The list of system's with this problem continues to grow.

I find it hard to believe the dev team has not addressed this issue someplace, maybe someone can point me to some relevant discussion on the issue.

02.05.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5704 Gigabit Ethernet (rev 10)

----------

## jlpoole

 *gunther222 wrote:*   

> The list of system's with this problem continues to grow.
> 
> I find it hard to believe the dev team has not addressed this issue someplace, maybe someone can point me to some relevant discussion on the issue.
> 
> 02.05.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5704 Gigabit Ethernet (rev 10)

 

I've been having the same problem on my SheevaPlug (Marvel ARM) and this work-around solved the problem.  Thank you!

 *Quote:*   

> MV-643xx 10/100/1000 ethernet driver version 1.4
> 
> mv643xx_eth smi: probed
> 
> net eth0: port 0 with MAC address 00:50:43:01:c1:36
> ...

 

----------

## taylorjonl

I had this same problem on some Intel cards, 8 in total.  Here are details on the devices/resources/drivers:

```
device   chipset      driver       address            pci

eth0    82571EB      e1000e      00:15:17:0d:**:**   0000:07:00.0

eth1   82571EB      e1000e      00:15:17:0d:**:**   0000:07:00.1

eth2   82571EB      e1000e      00:15:17:12:**:**   0000:04:00.0

eth3   82571EB      e1000e      00:15:17:12:**:**   0000:04:00.1

eth4   82574L      e1000e      00:e0:81:c5:**:**   0000:03:00.0

eth5   82574L      e1000e      00:e0:81:c5:**:**   0000:02:00.0

eth6   82576      igb         00:e0:81:c5:**:**   0000:09:00.0

eth7   82576      igb         00:e0:81:c5:**:**   0000:09:00.1
```

My system would fail on the first DHCP request but requests after startup worked fine.

I found that if I added 'dhcpcd_eth*="-t 90"' to my /etc/conf.d/net file(one per interface, replacing * with appropriate interface number) my system would boot up and get addresses correctly but it would take between 30-45 seconds per interface.

I tried starting DHCPCD by running 'rc-update add dhcpcd default', this resulted in about a 30-45 second DHCPCD startup time, all my interfaces initializations took under a second but only the last interface actually ended up with an IP address.  See the below results from my /var/log/rc.log file and my results from 'ifconfig | grep -B "inet addr"'.

```
rc default logging started at Sun Jan  8 15:33:43 2012

 * Starting syslog-ng ...

 [ ok ]

 * Starting network

 [ ok ]

 * Starting DHCP Client Daemon ...

 [ ok ]

 * Bringing up interface eth0

 *   dhcp ...

 *     Running dhcpcd ...

dhcpcd[2506]: sending commands to master dhcpcd process

 [ ok ]

 *     received address

 [ ok ]

 * Bringing up interface eth1

 *   dhcp ...

 *     Running dhcpcd ...

dhcpcd[2631]: sending commands to master dhcpcd process

 [ ok ]

 *     received address

 [ ok ]

 * Bringing up interface eth2

 *   dhcp ...

 *     Running dhcpcd ...

dhcpcd[2755]: sending commands to master dhcpcd process

 [ ok ]

 *     received address

 [ ok ]

 * Bringing up interface eth3

 *   dhcp ...

 *     Running dhcpcd ...

dhcpcd[2877]: sending commands to master dhcpcd process

 [ ok ]

 *     received address

 [ ok ]

 * Bringing up interface eth4

 *   dhcp ...

 *     Running dhcpcd ...

dhcpcd[2991]: sending commands to master dhcpcd process

 [ ok ]

 *     received address

 [ ok ]

 * Bringing up interface eth5

 *   dhcp ...

 *     Running dhcpcd ...

dhcpcd[3105]: sending commands to master dhcpcd process

 [ ok ]

 *     received address

 [ ok ]

 * Bringing up interface eth6

 *   dhcp ...

 *     Running dhcpcd ...

dhcpcd[3219]: sending commands to master dhcpcd process

 [ ok ]

 *     received address

 [ ok ]

 * Bringing up interface eth7

 *   dhcp ...

 *     Running dhcpcd ...

dhcpcd[3333]: sending commands to master dhcpcd process

 [ ok ]

 *     received address

 [ ok ]

 * Mounting network filesystems ...

 [ ok ]

 * Starting sshd ...

 [ ok ]

 * Doing udev cleanups

 * Starting vixie-cron ...

 [ ok ]

 * Starting local

 [ ok ]

rc default logging stopped at Sun Jan  8 15:34:24 2012

```

```
eth7      Link encap:Ethernet  HWaddr 00:e0:81:c5:97:5b

          inet addr:192.168.1.109  Bcast:192.168.1.255  Mask:255.255.255.0

--

lo        Link encap:Local Loopback

          inet addr:127.0.0.1  Mask:255.0.0.0

```

I am stumped on this, I can get it working but my boot-up time just for the network is 8x30-45 seconds.  I am not too familiar with what DHCPCD does on startup(/etc/init.d/dhcpcd start) but it takes 30-45 seconds.  I really want to figure this out so I can move on to the fun stuff, setting up Xen.

----------

