From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0 Description of problem: I get network packet errors when I use a static ipaddress. See below... If a allow my network address to be set using DHCP everything works great. I am current on all updates as of Aug 6, 2005. Also I have made the changes and reboot and get the same results. kernel running: uname -a 2.6.12-1.1398_FC4 #1 Fri Jul 15 00:52:32 EDT 2005 i686 i686 i386 which NIC model / manufacturer, info from: /sbin/lspci 01:0b.0 Ethernet controller: Lite-On Communications Inc LNE100TX grep eth0 /etc/modprobe.conf alias eth0 tulip Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. Use network configuration tool... Deactivate eth0 2. select --> Statically set IP address 3. Activate eth0 4. I get the following errors To clean up the errors. I change eth0 back to Automatically obtain IP address settings with dhcp Actual Results: ifconfig eth0 eth0 Link encap:Ethernet HWaddr 00:A0:CC:E6:94:AE inet addr:192.168.20.12 Bcast:192.168.20.255 Mask:255.255.255.0 inet6 addr: fe80::2a0:ccff:fee6:94ae/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:1313 errors:51 dropped:0 overruns:0 frame:17 TX packets:1360 errors:66 dropped:0 overruns:0 carrier:30 collisions:0 txqueuelen:1000 RX bytes:661901 (646.3 KiB) TX bytes:117653 (114.8 KiB) Interrupt:5 Base address:0x8000 When I ping the system from another box... Reply from 192.168.20.12: bytes=32 time=3995ms TTL=64 Reply from 192.168.20.12: bytes=32 time<1ms TTL=64 Reply from 192.168.20.12: bytes=32 time<1ms TTL=64 Request timed out. Reply from 192.168.20.12: bytes=32 time=714ms TTL=64 Request timed out. Reply from 192.168.20.12: bytes=32 time=2214ms TTL=64 Request timed out. Reply from 192.168.20.12: bytes=32 time=2714ms TTL=64 Reply from 192.168.20.12: bytes=32 time<1ms TTL=64 Request timed out. Reply from 192.168.20.12: bytes=32 time=1714ms TTL=64 Reply from 192.168.20.12: bytes=32 time<1ms TTL=64 Additional info: I have used mii-tool to turn on/off Auto-negotiation with no change.. I am using 100baseTx-HD hub.
If you still run FC4 - Is the hub really a switch ? Can you do an ethereal packet trace - does it show packet errors ? I have seen similar when a network switch is eg set to auto, but the card is set to any other setting, and vice-versa. Especially cisco switch (with port fast) and netgear consumer switches. Either both ends must use compatible auto (there are several kinds), or else both most be set to same setting. What happens is that the port continually tries to negiotiate, and for moments it can get packets out/in, but is bad most of the time. I also see this on windows machines that have been working perfectly and then one day a dreadfully slow on the network, toggle the auto to 100/full or to auto seems to immediately fix the problem !
This report targets the FC3 or FC4 products, which have now been EOL'd. Could you please check that it still applies to a current Fedora release, and either update the target product or close it ? Thanks.
Fedora Core 4 is no longer maintained. Setting status to "INSUFFICIENT_DATA". If you can reproduce this bug in the current Fedora release, please reopen this bug and assign it to the corresponding Fedora version.