Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
dhcpcd times out on first attempt. [WORKAROUND]
View unanswered posts
View posts from last 24 hours

 
Reply to topic    Gentoo Forums Forum Index Networking & Security
View previous topic :: View next topic  
Author Message
gunther222
n00b
n00b


Joined: 06 Sep 2006
Posts: 19

PostPosted: Tue Jun 14, 2011 3:56 pm    Post subject: dhcpcd times out on first attempt. [WORKAROUND] Reply with quote

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)

Code:

[    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.

Code:

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.

Code:

[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
Back to top
View user's profile Send private message
bjlockie
Veteran
Veteran


Joined: 18 Oct 2002
Posts: 1186
Location: Canada

PostPosted: Sun Jun 19, 2011 5:20 pm    Post subject: Reply with quote

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
r8169 0000:01:00.0: setting latency timer to 64
r8169 0000:01:00.0: irq 40 for MSI/MSI-X
r8169 0000:01:00.0: eth0: RTL8168b/8111b at 0xffffc90000010000, 00:19:66:13:f2:6
6, XID 18000000 IRQ 40


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?
_________________
AMD FX6100 CPU, 16 GiB RAM, OCZ Vertex 3 SSD
ASRock 970 Extreme3 motherboard with S/PDIF audio
Galaxy-NVidia GeForce 8800GT video card, Cyber Power CP550HG USB UPS
Back to top
View user's profile Send private message
Hu
Moderator
Moderator


Joined: 06 Mar 2007
Posts: 16464

PostPosted: Sun Jun 19, 2011 5:45 pm    Post subject: Reply with quote

bjlockie wrote:
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?
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.
Back to top
View user's profile Send private message
gunther222
n00b
n00b


Joined: 06 Sep 2006
Posts: 19

PostPosted: Sun Jun 19, 2011 6:37 pm    Post subject: Reply with quote

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

What is elibc_glibc?
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.



Hu nailed it right on the head, entirely correct.
Back to top
View user's profile Send private message
gunther222
n00b
n00b


Joined: 06 Sep 2006
Posts: 19

PostPosted: Mon Jun 27, 2011 5:56 am    Post subject: Still happening. Reply with quote

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.
Back to top
View user's profile Send private message
PoisonRO
n00b
n00b


Joined: 08 May 2011
Posts: 28
Location: Romania

PostPosted: Tue Jun 28, 2011 10:59 am    Post subject: Reply with quote

Hy,

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

Cheers,
Dan.
Back to top
View user's profile Send private message
bjlockie
Veteran
Veteran


Joined: 18 Oct 2002
Posts: 1186
Location: Canada

PostPosted: Thu Jun 30, 2011 6:47 pm    Post subject: Reply with quote

PoisonRO wrote:
Hy,

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

Cheers,
Dan.


Do you use elibc_glibc too?
_________________
AMD FX6100 CPU, 16 GiB RAM, OCZ Vertex 3 SSD
ASRock 970 Extreme3 motherboard with S/PDIF audio
Galaxy-NVidia GeForce 8800GT video card, Cyber Power CP550HG USB UPS
Back to top
View user's profile Send private message
chiefbag
Guru
Guru


Joined: 01 Oct 2010
Posts: 542
Location: The Kingdom

PostPosted: Thu Jun 30, 2011 7:41 pm    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
gunther222
n00b
n00b


Joined: 06 Sep 2006
Posts: 19

PostPosted: Fri Jul 01, 2011 1:42 am    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
chiefbag
Guru
Guru


Joined: 01 Oct 2010
Posts: 542
Location: The Kingdom

PostPosted: Fri Jul 01, 2011 10:39 am    Post subject: Reply with quote

Put the restart at the start of the dhcpd script instead.
Back to top
View user's profile Send private message
gunther222
n00b
n00b


Joined: 06 Sep 2006
Posts: 19

PostPosted: Sun Jul 03, 2011 2:45 am    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
gunther222
n00b
n00b


Joined: 06 Sep 2006
Posts: 19

PostPosted: Sun Jul 03, 2011 8:55 am    Post subject: Workaround. Reply with quote

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...
Code:

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...
Code:

# 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

Back to top
View user's profile Send private message
jkomar
Apprentice
Apprentice


Joined: 24 Sep 2004
Posts: 192
Location: Calgary, Canada

PostPosted: Thu Oct 13, 2011 7:46 pm    Post subject: Reply with quote

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
_________________
www.jbox.ca
www.flashinthepan.ca
stormfront Portage/Paludis overlay
Back to top
View user's profile Send private message
gunther222
n00b
n00b


Joined: 06 Sep 2006
Posts: 19

PostPosted: Fri Nov 04, 2011 1:30 pm    Post subject: Yet another adapter with the same issue. Reply with quote

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)
Back to top
View user's profile Send private message
jlpoole
Guru
Guru


Joined: 01 Nov 2005
Posts: 356
Location: Salem, OR

PostPosted: Sun Nov 06, 2011 3:20 pm    Post subject: Re: Yet another adapter with the same issue. Reply with quote

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
pegasus: v0.6.14 (2006/09/27), Pegasus/Pegasus II USB Ethernet driver
Back to top
View user's profile Send private message
taylorjonl
n00b
n00b


Joined: 02 Nov 2004
Posts: 13

PostPosted: Sun Jan 08, 2012 10:45 pm    Post subject: Reply with quote

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

Code:
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"'.

Code:
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

Code:
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.
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Networking & Security All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum