-   Linux - Networking (
-   -   Network not accessible after boot; OK after network restart (

chriswei 09-21-2004 07:04 PM

Network not accessible after boot; OK after network restart
Hi -

I'm using Fedora Core 2 on an old Dell XPS R450 with a basic Linksys ethernet card, connected to a Linksys WRT54G NAT box connected to my DSL modem.

When I boot Fedora, it says that eth0 is up, and ifconfig eth0 looks fine, but I can't ping any address (other than the PC's own address and, not even the router/gateway, and of course can't access anything past the gateway. If I then do a /etc/rc.d/init.d/network restart, everything is fine.

I'm not a Linux networking guru, but the configuration looks OK, and I've tried various suggestions with the scripts and files in /etc/sysconfig. The routing table shows a default route with the IP address of the gateway:
Destination Gateway Genmask *

This wouldn't be such a problem, but the Linux PC doesn't have a monitor (I'm accessing it remotely using SSH and VNC, since my one monitor is on my other PC), and to get it to boot and network, I have to keep switching the monitor over to the Linux PC and back again.

Any suggestions ? Could it be a bad network card? The Linksys WRT54G is new; could that cause a problem? The other PCs connected to the WRT54G all work fine.

Thanks much in advance,

- Chris

CroMagnon 09-21-2004 10:15 PM

OK, this is a really lame suggestion, but to save yourself switching the monitor all the time, why not add the network restart command to one of your startup scripts? :D

For testing purposes, disable the network script for startup (i.e, if you start in runlevel 3, remove the /etc/rc3.d/*network link). Once the system boots, log in and see if the network works properly if you do a /etc/rc.d/init.d/network start. If it does, perhaps it has something to do with the order the system is using. If it doesn't (but does after an extra network restart), then something is probably wrong in your network startup script.

chriswei 09-22-2004 09:43 AM

I removed the link to my *network file in rc5.d (I'm runlevel 5) and tried your suggestion. Here's what I saw:

After booting, I executed /etc/rc.d/init.d/network start, and it looked good, but I still couldn't ping anything in my subnet. I tried network restart after that, still no luck. Then I did an ifconfig eth0 down and up, and still no success. I then did at least one, maybe to network restarts, and it finally started to work.

I'm wondering if it might be a balky network card, or a strange interaction with my Linksys gateway. It used to work with my old Linksys gateway, but I hadn't booted the Linux box in several months (during this period the old gateway was replaced with the new one), so I couldn't say for sure that the new gateway is the cause. I've also tried several different ethernet cables, with no effect. I even moved the network card to another PCI slot, and that didn't help. Maybe I'll try swapping out the gateways and see what happens.

- Chris

rioguia 09-22-2004 10:50 AM

troubleshooting nics
is the cable good? try mii-tool (you should see "Link OK")

is the nic module being loaded? try lsmod and check against the driver listed at

is it possible that the address you have assigned your box is claimed by another? try arp

is the tcp/ip stack set? try ping (and make sure you post back the exact error messages)


ping 192.168.0.x (the questionable nic's IP address)

post the output of /etc/sysconfig/network-scripts/ifcfg-eth0; also, check your subnet ( would be standard on your local network but maybe your lynksys has a different setting?).

chriswei 09-22-2004 05:56 PM

Right after boot, mii-tool says "No link". I tried various cables, and got the same response. I also tried various ports on my Linksys router; same results.

lsmod shows the tulip driver (which I've heard is the correct one for the Linksys/Lite-On 100TX card), with size 40929 and 0 as the last number.

arp shows no conflicts.

ping works fine, as does ping (the Linux PC).

/etc/sysconfig/network-scripts/ifcfg-eth0 is as follows:


Subnet is

$ ifconfig eth0 says:

eth0 Link encap:Ethernet HWaddr 00:A0:CC:67:BC:58
inet addr: Bcast: Mask:
inet6 addr: fe80::2a0:ccff:fe67:bc58/64 Scope:Link
RX packets:529 errors:1 dropped:0 overruns:0 frame:0
TX packets:738 errors:18 dropped:0 overruns:0 carrier:21
collisions:0 txqueuelen:1000
RX bytes:390715 (381.5 Kb) TX bytes:114420 (111.7 Kb)
Interrupt:9 Base address:0x6000

I ran ifconfig eth0 after I had brought the link up, but when the PC first boots, it looks the same (with fewer RX and TX packets, however).

I noticed in /var/log/messages that during boot, the autonegotation for 10/100TX fails. When I ifconfig eth0 down and up, mii-tool says that eth0 is 10baseT, half-duplex (my router and card are 100baseTX). But during boot, it says it brings eth0 up successfully (no errors). dmesg says this about eth0: eth0: Lite-On PNIC-II rev 37 at 0x12836000, 00:A0:CC:67:BC:58, IRQ 9, and again, no errors indicated.

chriswei 09-22-2004 11:16 PM

I may have found a solution by pure chance. I did a google search for Linksys and Lite-On, which various logs and interfaces in Fedora called my network card, and I found this site:

which explains how to force the Linksys/Lite-On card into full-duplex 100baseTX mode. I followed the suggestions, and so far it has booted successfully three times in a row with the eth0 functioning properly.

To summarize, you add:

options tulip options=5

to the /etc/modprobe.conf file. The page above has a nice explanation.

Apparently what was happening was that the tulip driver was not putting the card into 100baseTX full-duplex mode on boot-up; in fact, it was in 10baseT half-duplex mode, and the above config option forces it to do so. I don't know why it would eventually work after boot if I manually brought the interface down and up, and issued several network restarts. I do know (from mii-tool) that previously it had never gone into 100baseTX full-duplex mode, even when it appeared to be working.

I'll let it sit overnight and test it again in the morning, to make sure it still works. Hopefully this will help others with the same problem.

Many thanks to rioguia and CroMagnon for their assistance.

- Chris

All times are GMT -5. The time now is 09:32 PM.