Bug 489735 - After a DHCP request timeout, NetworkManager does not reconnect when unplug/re-plug ethernet cable
After a DHCP request timeout, NetworkManager does not reconnect when unplug/r...
Status: CLOSED DUPLICATE of bug 453404
Product: Fedora
Classification: Fedora
Component: NetworkManager (Show other bugs)
10
All Linux
low Severity low
: ---
: ---
Assigned To: Dan Williams
Fedora Extras Quality Assurance
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-03-11 11:50 EDT by Rajeesh
Modified: 2009-03-16 13:17 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-03-16 13:17:43 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)

  None (edit)
Description Rajeesh 2009-03-11 11:50:35 EDT
Description of problem:

After a DHCP request timeout, NetworkManager doesn't reconnect even if ethernet cable is unplugged and re-plugged, or toggling "Enable Networking" button in NetworkManager Applet (gnome).

Problem can be replicated in two scenarios:
1. Wrongly connected to a network port (where no DCHP server is available) during boot. After login, I realize that no network is present, then unplugs the cable and connects to correct port (where DHCP server is available), but network is not activated automatically. Toggling the "Enable Networking" in applet doesn't help either.
2. Network cable is connected to an ADSL router/modem which has a dhcp server running. When power goes off, the router/modes goes offline and network connection is disconnected. When power comes back, NetworkManager immediately tries to reconnect, but fails because the DHCP server is not up yet. Then, even after DHCP server becomes up, unplugging/plugging or toggling "Enable Networking" doesn't help.

Workarounds:
1. Restart NetworkManager (after DHCP server becomes available)
2. Instead of toggling "Enable Networking", click on the applet and choose "System eth0" from "Wired Network". This will try to acquire network address again and succeeds.

The problem is that most of the users (yours truly included) tries only plugging/unplugging or toggling enable networking button, instead of the workarounds listed above, because it seems more intuitive naturally. It would be nice if network is activated at least on re-plugging network cable.

Version-Release number of selected component (if applicable):
NetworkManager-0.7.0.99-3.fc10.i386
NetworkManager-gnome-0.7.0.99-3.fc10.i386


How reproducible:
Always

Steps to Reproduce:
1. Please see above description
2.
3.
  
Actual results:


Expected results:


Additional info:
Excerpt from syslog during unplug/re-plug after DHCP timeout (inactive connection):
-------------------------------------------------------------
Mar 11 20:16:28 anish kernel: r8169: eth0: link down
Mar 11 20:16:28 anish NetworkManager: <info>  (eth0): carrier now OFF (device state 3)
Mar 11 20:16:28 anish NetworkManager: <info>  (eth0): device state change: 3 -> 2
Mar 11 20:16:28 anish NetworkManager: <info>  (eth0): deactivating device (reason: 40).
Mar 11 20:16:34 anish kernel: r8169: eth0: link up
Mar 11 20:16:34 anish NetworkManager: <info>  (eth0): carrier now ON (device state 2)
Mar 11 20:16:34 anish NetworkManager: <info>  (eth0): device state change: 2 -> 3

Excerpt from syslog on unplug/replug of an active connection:
-------------------------------------------------------------
Mar 11 20:37:46 anish kernel: r8169: eth0: link down
Mar 11 20:37:46 anish NetworkManager: <info>  (eth0): carrier now OFF (device state 8)
Mar 11 20:37:46 anish NetworkManager: <info>  (eth0): device state change: 8 -> 2
Mar 11 20:37:46 anish NetworkManager: <info>  (eth0): deactivating device (reason: 40).
Mar 11 20:37:47 anish NetworkManager: <info>  eth0: canceled DHCP transaction, dhcp client pid 28804
Mar 11 20:37:47 anish NetworkManager: <WARN>  check_one_route(): (eth0) error -34 returned from rtnl_route_del(): Sucess#012
Mar 11 20:37:59 anish kernel: r8169: eth0: link up
Mar 11 20:37:59 anish NetworkManager: <info>  (eth0): carrier now ON (device state 2)
Mar 11 20:37:59 anish NetworkManager: <info>  (eth0): device state change: 2 -> 3
Mar 11 20:37:59 anish NetworkManager: <info>  Activation (eth0) starting connection 'System eth0'
Mar 11 20:37:59 anish NetworkManager: <info>  (eth0): device state change: 3 -> 4
Mar 11 20:37:59 anish NetworkManager: <info>  Activation (eth0) Stage 1 of 5 (Device Prepare) scheduled...
...

I tracked the code till "src/nm-device.c:2386 {nm_device_state_changed}". Any pointer to debug further is appreciated. If you need any additional info, please ask. [This behaviour has been present since a long time, but I had workarounds available, I could find time to file a bug only now :-( ]
Comment 1 Jessica Sterling 2009-03-14 21:01:36 EDT

*** This bug has been marked as a duplicate of bug 489398 ***
Comment 2 Rajeesh 2009-03-15 01:56:13 EDT
No, this bug is not the duplicate of 489398

If my DHCP server is up, my eth0 *will* connect automatically on boot. There is no problem with that. And yes, I have ONBOOT=yes in my ifcfg-eth0 script.

The issue happens only when DHCP server goes offline. NM tries to reconnect immediately, which fails for obvious reasons. But when the DHCP server is up, if I do either unplug/re-plug the ethernet cable, or toggle the "Enable Networking" checkbox in NM applet, no attempt to activate eth0 is made.

But if I restart NM, or simply choose "System eth0" from the connections, eth0 is reconnected.

And, this is not a problem with the latest update. This behaviour has been around for a long time. Maybe from the days of F9, I guess.
So I'd like reopening it.
Comment 3 Jessica Sterling 2009-03-15 09:22:25 EDT
I see.  Thank you for your update.

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 4 Dan Williams 2009-03-16 13:17:43 EDT

*** This bug has been marked as a duplicate of bug 453404 ***

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