Red Hat Bugzilla – Bug 218026
network connection hang unexpectedly after a period of time
Last modified: 2008-08-02 19:40:33 EDT
Description of problem:
ok, so i have a Pentium D at 2,8 Ghz w/HT and 2 GB Ram with a Asus P5ND2
motherboard and an Gbit ethernet controller incorporated (INTEL). the fact is
that i'm running or i'm planning to run on this box an web server, mail server
and ftp server. everything works well from this computer to the internet, 0%
ping losses, mtr to yahoo.com or anything else show the correct path, but when
i'm trying to access this computer(server) from the outside, it work if only i
make traffic all the time,if i let him idle form about 5 - 10 min, it hang.The
only way i could restore the connection is to ping that box. I've made all the
updates but still the problem remains. Could someone help me, i don't know what
else should i do. The firewall that i am using is the original version of that
one that came with the fedora core distrib.
Version-Release number of selected component (if applicable):
i use :
Linux Gandalf 2.6.18-1.2849.fc6 #1 SMP Fri Nov 10 12:45:28 EST 2006 i686 i686
with nForce drivers version :
Release Date: August 21, 2006
Download V 1.11
Steps to Reproduce:
It's not working.
To find answers.
Ok .. this report is not very helpful for me.
Have you tried switching on/off the firewall?
Do you run with SELinux?
Can you dump the traffic on you box and send it here? (tcpdump or wireshark is
Do you see a bug in some specific net-tools component?
Created attachment 142561 [details]
traffic information for eth0 - i've used tcpdump
SELinux feature is disabled;
Even if firewall is off/on the problem still exist.
i don't know where is the problem, but it seem to be a network problem, because
the hardware configuration seems to be ok :
06:0c.0 Ethernet controller: Intel Corporation 82540EM Gigabit Ethernet
Controller (rev 02)
Subsystem: ASUSTeK Computer Inc. Unknown device 80ee
Flags: bus master, 66MHz, medium devsel, latency 32, IRQ 66
Memory at da000000 (32-bit, non-prefetchable) [size=128K]
I/O ports at a000 [size=64]
Capabilities: [dc] Power Management version 2
Capabilities: [e4] PCI-X non-bridge device
Capabilities: [f0] Message Signalled Interrupts: 64bit+ Queue=0/0 Enable-
1) May be some link negotiation problem ?
Can try watch please what link actually is doing:
watch --interval .2 'ethtool eth0'
2) Instead of just "make traffic" to wake up the link can try reset
conntroler card PHY interface:
ethtool -r eth0 [maybe]
It will make your link work again ?
3) If point 2 prove to have some sort of link negociation problem try force
in 100/full mode and switch autoneg off:
ethtool -s eth0 speed 100 duplex full autoneg off
I am curious if is a software bug, or actually it is a usual negotiation
bug between NIC and switch, which in other hand are common :-)
BTW, in you dmesg appear some sort of messages related to intel eepro driver ?
I can confirm frequent hangs with this adapter.
Intel Corporation 82540EM Gigabit Ethernet Controller (rev 02)
One piece of info is that the system was running fine until I
switched from a static IP to dhcp. Tomorrow I will try to find
a new static IP number and try it again.
It is working great with a static IP!
That mean the problem is in the userland not in kernel or driver related and
i can guess that somehow your dhclient session against that card recieve some
strange option fields in dhcp-offer packet and try to renegotiate by flapping
your status of the card, or even dhcp server somehow dont like your dhclient
acknowledge and reject you after a while.
For further investigation would be very helpfull for us in this case to make
us a sniff of your dhcp aquire sesion like this:
tethereal -i ethX -V port bootpc or port bootps > debug.txt
Than please attach the text file in this bugreport, i can look into the dhcp
session to see if something goes wrong regarding dhcp session.
Fedora apologizes that these issues have not been resolved yet. We're
sorry it's taken so long for your bug to be properly triaged and acted
on. We appreciate the time you took to report this issue and want to
make sure no important bugs slip through the cracks.
If you're currently running a version of Fedora Core between 1 and 6,
please note that Fedora no longer maintains these releases. We strongly
encourage you to upgrade to a current Fedora release. In order to
refocus our efforts as a project we are flagging all of the open bugs
for releases which are no longer maintained and closing them.
If this bug is still open against Fedora Core 1 through 6, thirty days
from now, it will be closed 'WONTFIX'. If you can reporduce this bug in
the latest Fedora version, please change to the respective version. If
you are unable to do this, please add a comment to this bug requesting
Thanks for your help, and we apologize again that we haven't handled
these issues to this point.
The process we are following is outlined here:
We will be following the process here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this
doesn't happen again.
And if you'd like to join the bug triage team to help make things
better, check out http://fedoraproject.org/wiki/BugZappers