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 127.0.0.1), 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
192.168.0.0 * 255.255.255.0
default 192.168.0.1 0.0.0.0

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

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.

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

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 www.scyld.com/network.html

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 127.0.0.1

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 (255.255.255.0 would be standard on your local network but maybe your lynksys has a different setting?).

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 127.0.0.1 works fine, as does ping 192.168.0.105 (the Linux PC).

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

DEVICE=eth0
ONBOOT=yes
BOOTPROTO=none
IPADDR=192.168.0.105
NETMASK=255.255.255.0
GATEWAY=192.168.0.1
TYPE=Ethernet

Subnet is 255.255.255.0

$ ifconfig eth0 says:

eth0 Link encap:Ethernet HWaddr 00:A0:CC:67:BC:58
inet addr:192.168.0.105 Bcast:192.168.0.255 Mask:255.255.255.0
inet6 addr: fe80::2a0:ccff:fe67:bc58/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
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.

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:

http://mpickering.homeip.net/phpwiki...php/FedoraCore

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