Hi, I am starting /etc/ini.d/net.eth0, which is on an USR 9003 ADSL router. In the past eth0 was coming up almost instantly. But a few months ago (last year), you guys changed the baselayout scripts to make it able to detect if the cable was pluged in or not. Since, eth0 is taking almost 1 minute to come up... very anoying. I reported this problem but I didn't get fixed, the new script was having troubles and many changes were applied, and I didn't follow to the end. At that time, I was using the onboard ethernet of an ABIT card (different ethernet than I am using today). Today, I am using an ASUS P4C800-Deluxe with an onboard 3COM 3C940 (sk98lin module). Gentoo was installed from scratch 1 week ago. So, I now have the same problem on these 2 different machines since you changed the baselayout script. Thanks for your help. $ emerge baselayout -p These are the packages that I would merge, in order: Calculating dependencies ...done! [ebuild R ] sys-apps/baselayout-1.8.6.13-r1 # /etc/conf.d/net: # $Header: /home/cvsroot/gentoo-src/rc-scripts/etc/conf.d/net,v 1.7 2002/11/18 19:39:22 azarah Exp $ # Global config file for net.* rc-scripts # This is basically the ifconfig argument without the ifconfig $iface # #iface_eth0="192.168.1.3 broadcast 192.168.1.255 netmask 255.255.255.0" #iface_eth1="207.170.82.202 broadcast 207.0.255.255 netmask 255.255.0.0" # For DHCP set iface_eth? to "dhcp" # For passing options to dhcpcd use dhcpcd_eth? # iface_eth0="dhcp" #dhcpcd_eth0="..." # For adding aliases to a interface # #alias_eth0="192.168.0.3 192.168.0.4" # NB: The next is only used for aliases. # # To add a custom netmask/broadcast address to created aliases, # uncomment and change accordingly. Leave commented to assign # defaults for that interface. # #broadcast_eth0="192.168.0.255 192.168.0.255" #netmask_eth0="255.255.255.0 255.255.255.0" # For setting the default gateway # #gateway="eth0/192.168.0.1"
The net.eth0 script installed by baselayout no longer includes the carrier detection (it was bug 33272, which is still open for some reason, though it no longer applies). Since you say it takes 1 minute, since you're using DHCP, and since 60 seconds is the exact default timeout used for dhcpcd, it sounds very likely that either there is no DHCP server on your network to answer, or the DHCP server isn't responding to you (or perhaps just isn't giving you an IP). Take a look in your error logs - /var/log/syslog particularly - to see if you see dhcpcd error messages such as: dhcpcd[9581]: timed out waiting for a valid DHCP server response Personally I've added a "-t 10" to my dhcpcd_eth1 variable to /etc/conf.d/net on my notebook so that I don't have to wait a full minute when I boot it without a network connection.
There seems to be no error in the logs. After 1 minute eth0 comes always up right, only that it takes 1 minute. I have added the "-t 10" option as you suggested and eth0 now comes up very fast. Now I wonder why it is waiting for the full minute if the default timeout is set ? Is there still something wrong with the scripts ? Thanks a lot for your help.
default dhcp timeout is 60 seconds
Well, as I understand it, a default timeout of 60 seconds means that if nothing happens or it can't get a response, it won't wait longer than 60 seconds, but if it gets a response after 5 seconds it exits the loop and doesn't wait any longer). So, as it seems now, ALL gentoo boxes with the default config have to wait the full 60 seconds at every boot up ? That's rather strange to me... as it was working quite well in earlier versions of baselayout when eth0 was up in 1 or 2 seconds... For this reason, I am reopening the bug. If I am wrong, and *everyone* really *has to* wait 60 seconds at every boot up please mark it resolved-invalid again. Thanks for your time.
No, dhcpcd normally gets an address long before the timeout. This works fine for most people so I believe the problem is in your DHCP server. You should try using the -d option to dhcpcd to enable debugging and watch the system log to see what is happening. See dhcpcd(8) If you narrow this down to a proven problem in the Gentoo startup, please feel free to re-open this bug.
