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:
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?
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-
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 ?
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.
It is working great with a static IP!
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.
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