Description of problem: My machine is connected via DHCP over Ethernet. In two days of use of Fedora 11, I have twice discovered the network disconnected. Web pages would not load and Firefox went offline. The Network Configuration application showed eth0 as "inactive." Clicking "activate" returned the network to operation. This machine never had network connection problems under Fedora 10. Other computers connected to the same DHCP server were not disconnected. Examining /var/log/messages shows startup chatter, then a 2 hour gap while I was not using the machine. During this time I started Firefox and looked at a few pages. No error messages. Next messages are kernel: eth0: setting full-duplex. NetworkManager: <info> (eth0): carrier now ON (device state 1) and then a burst of messages from dnclient, avahi-daemon, ntpd. Version-Release number of selected component (if applicable): system-config-network 1.5.97 How reproducible: Only happens when you don't want it to. Steps to Reproduce: 1. Boot Fedora 11. 2. Wait for network disconnect. 3.
Further problems with this machine. I was doing a "yum update" of 95 modules. Half way through, yum began to report "temporary failure in name resolution." I opened the Network Configuration control panel. eth0 was active. I decided to deactivate and activate it, which seemed to help before. eth0 deactivated but would not reactivate. After a long wait "Determining IP information for eth0..." it reported that it failed. Tried this a couple of times, same result. Network card is a 3Com 3c905c-tx/tx-m[Tornado] if that matters. Upstream is a hub, and further up an Apple AirPort Express, the DHCP server. Other Ethernet devices in this net are working. /var/log/messages is full of monk kernel: eth0: setting full-duplex. monk kernel: eth0: Host error, FIFO diagnostic register 0000. monk kernel: eth0: PCI bus error, bus status 80000020 ending with a "too much work in interrupt" and "carrier now OFF" Rebooted. eth0 was inactive. Activated it, worked. I see this is by design. Cannot use the advice in http://fedorasolved.org/Members/khaytsus/go-online-automatically-at-boot to fix it because it says "device not managed" where "system eth0" appears in the instructions.
Thanks for filling this bug. Can you please attach you complete /var/log/messages after you experience this problem? -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
See the tarfile submitted as additional info for bug 513453, which contains a /var/log/messages and output from nm-tool. I trimmed out about 90,000 repeated lines from messages to reduce the file size by a factor of 10.
IT IS EXTREMELY SERIOUS BUG... NETWORK MANAGER MESSES UP S-C-N and S-C-N-tui too when it was not supposed to do so Network Manager also loses connectivity (not name res. but ping too) Kernel has again nothing to do with it DHCP has nothing to do with it
Also, communication of networking capability to thunderbird has been messed up, while mozilla is fine
Similar problem with Fedora 11. My IP information and DNS are statically configured. Issue occurs on eith eth0 and eth1. Upon a reboot and startup all network connectivity appears to be working normally: NFS, SSH, APACHE. After about ten mintues network connectivity is lost. With no intervention the connection will re-establish in about three to five minutes. When relogging in via SSH I notice the windows mount points are locked and cannot be umounted with either -f or -l option of umount. About every ten or so minutes the system will loose network connectivity again.
Please disregard Comment #6. My problem appears to be related to assigning a static IP address from a DHCP range. I was competing with another machine which had obtained the lease of the IP address. Reassigned the addressed to a static IP range and the problem went away.
The original bug here seems to be due to your switch or computer dropping the link, which is indistinguishable from the cable being unplugged. NM 0.8 in Fedora 12 and later will allow a few seconds for a dropped link before tearing down the connection and retrying it. Can you find out how long the link is down from the kernel logs? kernel: eth0: setting full-duplex. NetworkManager: <info> (eth0): carrier now ON (device state 1) You should also see some messages about the carrier being OFF. The spurt of activity from avahi and ntpd is exactly because the link went down and is now back up.
NetworkManager in Fedora 12 gives wired links a 4-second grace period to come back after they drop before taking the device down. Also note that you probably don't want to use ifup/ifdown and the Network Device Control applet at the same time as NetworkManager is active, *unless* you set NM_CONTROLLED=no in the device's ifcfg file that you want NetworkManager to ignore. For those of you with the original problem, please let me know how long the link was down, or if there was otherwise a connectivity problem with your link, and for how long that occurred. If you run into this again, you can grab /var/log/messages which should clearly show the issue.
Created attachment 374395 [details] /var/log/messages This bug is really annoying. It happens every few days for me. This time I tracked it down and have included /var/log/messages which shows what's going on. First of all: my network setup: the machine has a wired network connection with a fixed IP address, but that IP address is allocated by my DHCP server based on the machine's mac address. Unfortunately my DHCP server is located in another part of the building over a wifi bridge (to be resolved when I move house ...) If you look at /var/log/messages you can see what happened just after 03:00 this morning. dhclient lost contact with the DHCP server. This wasn't a permanent failure - the DHCP server would have come back soon after. But NM decided to drop the eth0 interface, which made the loss effectively permanent. I recovered the network at 11:53 this morning by manually activating it from the console. It would help if NM had a much longer tolerance for these sorts of outages.
Yeah, there's a bug open somewhere (either gnome.org or redhat.com) about periodically retrying a connection if the DHCP server fails to respond to a lease renewal.
This message is a reminder that Fedora 11 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 11. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '11'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 11's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 11 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
*** This bug has been marked as a duplicate of bug 453404 ***
nets wents down when i change mac adress