From Bugzilla Helper: User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; Q312461) Description of problem: On a Dell Lattitude w/ the docking station (and a 3Com 900 NIC), mii-tool reports a "no-link" status...when in fact there is a link and I can manually configure the card Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. boot up 2. start network - fails. run mii-tool in NIC 3. reports no-link Actual Results: reports no link Expected Results: should report link Additional info:
Similar problem. /etc/init.d/network fails to start up eth0 because mii-tools says that there is no link. I bring up eth0 by hand and mii-tools still says that there is no link. Driver is 8139too. Similar problem is described in http://www.scyld.com/pipermail/realtek/2002-June/001389.html and claimed to be fixed in 2.4.19-pre10.
Arjan, this appears to be a driver issue..?
does ethtool work?
ethtool also says "Link detected: no" This was not a problem in 7.3 because ifup did not use the function check_link_down (defined in /etc/sysconfig/network-scripts/network-functions) which uses mii-tools. The (null) ifup script calls check_link_down which calls mii-tools. mii-tools says there is no link. This means that /etc/init.d/nework does not even try to bring up eth0. So maybe, its driver bugginess made important by a change in init script.
The problem is a bug in check_link_down. ip link show $device may work properly even when mii-tool or ethtool don't work. I have the problem described here with my Orinoco card. The attached patch to /etc/sysconfig/network-scripts/network-functions as included with initscripts-7.04-1 fixes the problem. I haven't tested this thoroughly with other configurations, but it does at least accurately detect lnk down on my wired card and work on my wireless card. -
Oops -- I committed before I was finished typing. I was going to add that my patch assumes that ip link show $device | grep -q UP indicating that UP is present means that the link is up. I was also about to delete the sentence "I haven't tested ..." and change it to say that this works with my wired ethernet card both with link down and link up as well as with my wireless card. I'll attach the patch now.
Created attachment 90017 [details] patch to check_link_down in network-functions patch relative to /etc/sysconfig/network-scripts/network-functions as in initscripts-7.04-1
Hmm. Maybe this was the wrong bug to post my comments to. My problem is strictly phoebe-related.
Comment on attachment 90017 [details] patch to check_link_down in network-functions ignore this. It's wrong.
Please pardon all my noise. I was confused. Let's just pretend I never posted to this bug. I was reporting an incorrect fix for a non-problem that wasn't related to this bug. I'm no longer confused. Sorry about that.
This sounds like an initscript/kernel issue rather than a net-tools one, so reassigning bug to initscripts. Read ya, Phil
The only way this can be considered an initscript bug is if you just *don't* want to check link status in the initscripts. But mii-tool is OBVIOUSLY broken. And this is on RedHat 9, so it still exists. Tell me how it would be possible if mii-tool reported no link status but the interfaces is configured and can ping its gateway?? I really think that has gone on far too long - for 2 full stable revs of the OS, this hasn't worked correctly. And the worst part is that the OS would be COMPLETELY UNUSABLE if the person weren't saavy enough to comment out the mii-tool exit status in the startup script. That's the ONLY way you can get the system to startup with a working network connection. Dell Latittude CP w/ 3c905C-TX/TX-M in docking station... [root@xyz root]# /sbin/mii-tool eth0 eth0: 10 Mbit, half duplex, no link [root@xyz root]# /sbin/ethtool eth0 Settings for eth0: No data available [root@xyz root]# ping 172.17.20.1 PING 172.17.20.1 (172.17.20.1) 56(84) bytes of data. 64 bytes from 172.17.20.1: icmp_seq=1 ttl=255 time=0.352 ms 64 bytes from 172.17.20.1: icmp_seq=2 ttl=255 time=0.310 ms 64 bytes from 172.17.20.1: icmp_seq=3 ttl=255 time=0.318 ms --- 172.17.20.1 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 1998ms rtt min/avg/max/mdev = 0.310/0.326/0.352/0.027 ms [root@xyz root]#
If mii-tool doesn't report the status correctly, even though the driver supports mii-tool, that's usually a driver issue.
Seems to work for me in our 2.4.20 errata tree - does it work for you too
mii-tool and ethtool report the correct link status under 2.4.20-13.8 and 8139too driver.
Latest RedHat 9, all updates including kernel-2.4.20-18.9....still doesn't work correctly for me. :-( This is with 3c905 driver...
3c59x you mean surely ?
yes...sorry $ cat /etc/modules.conf [...] alias eth0 3c59x
I'm having this same issue with a 3c905b (cyclone) rev 64 card. using the 3c59x driver in Fedora Core 1. This bug has popped up several time (just do a bugzilla search for MII) Mandrake has a fix for this, by setting a variable int he ifcfg-eth0 script NO_MII_SUPPORT=yes. then having the network-functions check_mii_tool return success if MII is disabled for that interface.. This should definitely be added into the Stock RH/Fedora initscripts to work around faulty drivers/mii_tool issues.
Thanks for the bug report. However, Red Hat no longer maintains this version of the product. Please upgrade to the latest version and open a new bug if the problem persists. The Fedora Legacy project (http://fedoralegacy.org/) maintains some older releases, and if you believe this bug is interesting to them, please report the problem in the bug tracker at: http://bugzilla.fedora.us/