You are not logged in.
Hi everybody,
I know this problem has already arisen many times in the forums, but none of the remedies I've seen here so far seems to work for me. The problem is dhcp: it doesn't get the network up and times out during boot.
I have been experiencing that for many months, but as it has been occurring occasionally (say 1 out of 5 boots), I have just rebooted (apparently relaunching with /etc/rc.d/network restart, even 7-8 times in a row, doesn't work. Only rebooting does it), and that was it.
But since last week it has turned into the other way around: 1 out of 5 or more times it works, making the whole thing unusable. Currently I can't have network up since yesterday, 10-15 unsuccessful attempts so far.
Let me give out some data:
I have a triple boot: 1 windows xp, 1 arch with kde, 1 arch with gnome. An ADSL cabled connection to a modem/router. Windows always works, no network hassles at all, so it's not a hardware problem.
frnc [~/] $> uname -a
Linux myhost 2.6.35-ARCH #2 SMP PREEMPT Sat Aug 14 21:58:00 CEST 2010 x86_64 Intel(R) Core(TM)2 CPU 6400 @ 2.13GHz GenuineIntel GNU/Linux
frnc [~/] $> sudo pacman -Qi dhcpcd
Nome : dhcpcd
Versione : 5.2.7-1
[...]
Installato il : lun 09 ago 2010 15:31:06 CEST
lspci
[...]
03:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 01)
05:02.0 Ethernet controller: D-Link System Inc RTL8139 Ethernet (rev 10)
lsmod
[...]
r8169 38078 0
8139too 21105 0
[...]
As I get into a networkless system after the timeout, this is what I do:
frnc [~/] $> sudo dhcpcd -k eth0
dhcpcd[2132]: dhcpcd not running
[root@myhost frnc]# dhcpcd -nd eth0
dhcpcd[2168]: version 5.2.7 starting
dhcpcd[2168]: eth0: executing `/usr/lib/dhcpcd/dhcpcd-run-hooks', reason PREINIT
dhcpcd[2168]: eth0: executing `/usr/lib/dhcpcd/dhcpcd-run-hooks', reason
NOCARRIER
dhcpcd[2168]: eth0: waiting for carrier
dhcpcd[2168]: timed out
[root@myhost frnc]# dhcpcd -nd -t 60 eth0
dhcpcd[2214]: version 5.2.7 starting
dhcpcd[2214]: eth0: executing `/usr/lib/dhcpcd/dhcpcd-run-hooks', reason PREINIT
dhcpcd[2214]: eth0: executing `/usr/lib/dhcpcd/dhcpcd-run-hooks', reason
NOCARRIER
dhcpcd[2214]: eth0: waiting for carrier
dhcpcd[2214]: timed out
Another option would be trying with dhclient, which I found might be an alternative:
[root@myhost frnc]# pacman -Qi dhclient
Nome : dhclient
Versione : 4.2.0-1
[...]
Installato il : gio 19 ago 2010 10:41:33 CEST
[root@myhost frnc]# dhclient -v eth0
Internet Systems Consortium DHCP Client 4.2.0
Copyright 2004-2010 Internet Systems Consortium.
All rights reserved.
For info, please visit [url]https://www.isc.org/software/dhcp/[/url]
can't create /var/db/dhclient.leases: No such file or directory
Listening on LPF/eth0/00:15:e9:f1:0b:27
Sending on LPF/eth0/00:15:e9:f1:0b:27
Sending on Socket/fallback
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 6
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 8
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 14
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 17
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 16
No DHCPOFFERS received.
No working leases in persistent database - sleeping.
Observations:
I have tried to redo the same above with eth1 -- nothing.
Then I deleted the lease file in /var/lib/dhcpcd/namefile.lease, as suggested in https://bbs.archlinux.org/viewtopic.php?id=101613 (couldn't find the /var/db directory though), but nothing.
Commented out require dhcp_server_identifier in /etc/dhcpcd.conf, as suggested in https://bbs.archlinux.org/viewtopic.php?id=81034. Nothing.
Anyway can't be a configuration problem I guess, since sometimes the thing works.
Curiously, this thing moves back and forth between the 2 arch installations. A month ago it was affecting the one with kde, which later started to work the normal way (normal way = 1 failure out of about 5 boots), now it's the gnome one's turn. Please note: both installations have the same version of dhcpcd.
Someone said the problem might be related to the multi-boot, as the windows driver might possibly turn off the network card. In my experience that is not the question. Currently rebooting arch-gnome results in a timeout, rebooting arch-kde immediately after is likely to be ok, no matter whether you previously used windows or not.
Turning off and on the modem/router (see https://bbs.archlinux.org/viewtopic.php?id=100152&p=3) doesn't seem to produce any effect either (anyway, not a viable solution for me because the modem is actually on a another floor).
I know there is a (closed) bug about this (http://bugs.archlinux.org/task/17838).
I have no clues.
Anyone can help? Thanks in advance.
Last edited by frnc (2010-08-22 09:15:56)
Offline
Do you have any networking problems when you set up a static IP ?
The 'eth0: waiting for carrier' line in the dhcpcd output seems a bit suspect to me. Have you tried starting dhcpcd with the '-K' option ?
Offline
Thank you very much for your answer. It seems that you put me on the right path. Now things are working, even though I wonder how long. I post what I've done so far just in case someone comes across this.
The 'eth0: waiting for carrier' line in the dhcpcd output seems a bit suspect to me. Have you tried starting dhcpcd with the '-K' option ?
I've tried it out 5-6 more times.
[root@myhost frnc]# dhcpcd -K eth0
dhcpcd[2104]: version 5.2.7 starting
dhcpcd[2104]: eth0: rebinding lease of 192.168.1.141
dhcpcd[2104]: eth0: broadcasting for a lease
dhcpcd[2104]: timed out
As expected. Anyway, omitting the trailing "eth0"...
[root@myhost frnc]# dhcpcd -K
dhcpcd[2196]: version 5.2.7 starting
dhcpcd[2196]: eth0: rebinding lease of 192.168.1.141
dhcpcd[2196]: eth1: broadcasting for a lease
dhcpcd[2196]: eth1: offered 192.168.1.141 from 192.168.1.1
dhcpcd[2196]: eth1: acknowledged 192.168.1.141 from 192.168.1.1
dhcpcd[2196]: eth1: checking for 192.168.1.141
dhcpcd[2196]: eth1: leased 192.168.1.141 for 21600 seconds
dhcpcd[2196]: forked to background, child pid 2221
What's odd is:
[root@myhost frnc]# route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
192.168.1.0 * 255.255.255.0 U 203 0 0 eth1
default alicegate.homen 0.0.0.0 UG 203 0 0 eth1
which is wrong, because no wire is currently in the eth1 port... this puzzles me quite a bit. To get a confirmation:
[root@myhost frnc]# ifconfig -a
eth0 Link encap:Ethernet HWaddr 00:15:E9:F1:0B:27
UP BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
Interrupt:23 Base address:0x4c00
eth1 Link encap:Ethernet HWaddr 00:18:F3:8A:EE:04
inet addr:192.168.1.141 Bcast:192.168.1.255 Mask:255.255.255.0
inet6 addr: fe80::218:f3ff:fe8a:ee04/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:1165 errors:0 dropped:0 overruns:0 frame:0
TX packets:1335 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:488306 (476.8 Kb) TX bytes:219131 (213.9 Kb)
Interrupt:44 Base address:0xa000
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:24 errors:0 dropped:0 overruns:0 frame:0
TX packets:24 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:1280 (1.2 Kb) TX bytes:1280 (1.2 Kb)
So the next assumption is that for some reason arch swapped ethernet port names. I tried to modify /etc/rc.conf accordingly:
eth1="dhcp"
INTERFACES=(eth1)
But it turns out that sometimes that fails too, and neither ports get an IP address.
So, final workaround: remove network from the daemons list in /etc/rc.conf, put dhcpcd -K in /etc/rc.local. As far as I've seen, in this way sometimes arch brings up eth0, some other times it brings up eth1. No idea why, but it works so far.
Thank you hexanol for your hint.
Offline
Perhaps http://wiki.archlinux.org/index.php/Con … es_varying can help you.
Offline
You're welcome. It definitely looks like an interface naming problem (i.e. when you boot your system, you don't know which name will be associated to each interface), and that would explain all the behaviour you described.
Offline
Perhaps http://wiki.archlinux.org/index.php/Con … es_varying can help you.
thanks to fr33ke too. I completely overlooked that in arch documentation (actually, overlooking was easy since it was unclear that the problem was the two ethernet ports...).
Offline
Thanks fr33ke. This was a long standing annoyance for me too. http://wiki.archlinux.org/index.php/Con … es_varying helped solve the issue.
Offline