Bug 218026 - network connection hang unexpectedly after a period of time
network connection hang unexpectedly after a period of time
Status: CLOSED INSUFFICIENT_DATA
Product: Fedora
Classification: Fedora
Component: net-tools (Show other bugs)
6
i386 Linux
medium Severity high
: ---
: ---
Assigned To: Radek Vokal
Ben Levenson
bzcl34nup
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-12-01 07:20 EST by Andrei Claudiu Tatulescu
Modified: 2008-08-02 19:40 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-05-06 04:10:33 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
traffic information for eth0 - i've used tcpdump (125.24 KB, application/octet-stream)
2006-12-01 07:45 EST, Andrei Claudiu Tatulescu
no flags Details

  None (edit)
Description Andrei Claudiu Tatulescu 2006-12-01 07:20:40 EST
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
i386 GNU/Linux

with nForce drivers version :
Version: 1.11
Release Date: August 21, 2006
Download V 1.11


How reproducible:


Steps to Reproduce:
1.
2.
3.
  
Actual results:

It's not working.

Expected results:
To find answers.

Additional info:
Comment 1 Radek Vokal 2006-12-01 07:24:45 EST
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
very useful)
Do you see a bug in some specific net-tools component?
Comment 2 Andrei Claudiu Tatulescu 2006-12-01 07:45:50 EST
Created attachment 142561 [details]
traffic information for eth0 - i've used tcpdump
Comment 3 Andrei Claudiu Tatulescu 2006-12-01 07:51:52 EST
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-
Comment 4 Andrei Claudiu Tatulescu 2006-12-01 08:16:29 EST
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-
Comment 5 Balint Cristian 2006-12-12 04:13:14 EST
Hello,

  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 ?
Comment 6 Sammy 2007-01-04 19:49:40 EST
I can confirm frequent hangs with this adapter.

I have:
Intel Corporation 82540EM Gigabit Ethernet Controller (rev 02)
Running 2.6.18-1.2869.fc6.

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.
Comment 7 Sammy 2007-01-05 09:40:17 EST
It is working great with a static IP!
Comment 8 Balint Cristian 2007-01-06 07:08:35 EST
Hello Andrei,

  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.
Comment 9 Bug Zapper 2008-04-04 01:02:50 EDT
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.
http://fedoraproject.org/wiki/LifeCycle/EOL

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
the change.

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:
http://fedoraproject.org/wiki/BugZappers/F9CleanUp

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

Note You need to log in before you can comment on or make changes to this bug.