NetworkManager does not retry DHCP after DHCP timed out once

Bug #387035 reported by David Tomaschik
24
This bug affects 3 people
Affects Status Importance Assigned to Milestone
NetworkManager
Fix Released
Wishlist
network-manager (Debian)
Confirmed
Unknown
network-manager (Ubuntu)
Confirmed
Wishlist
Unassigned

Bug Description

Binary package hint: network-manager

Source package hint: network-manager

I have a computer with Jaunty on it connected directly to a Linksys home network router running OpenWRT. If the router is rebooted, network-manager times out trying to get a new DHCP address before the DHCP server is back up. This results in network-manager leaving the interface down and the system unreachable. It would be nice if network-manager would retry the connection after, perhaps, 1 minute, then 2 minutes, then 5, and finally 10 before giving up.

Revision history for this message
Alexander Sack (asac) wrote :

upstream bug: http://bugzilla.gnome.org/show_bug.cgi?id=511581 ... please follow discussion there.

Changed in network-manager (Ubuntu):
importance: Undecided → Wishlist
status: New → Triaged
Changed in network-manager:
status: Unknown → Confirmed
Revision history for this message
Oscar Manuel Gómez Senovilla (omgs) wrote :

I don't have an account for there, and not sure if my problem is the same, so I'll try to fully describe it.

I have a laptop (Acer aspire 5612WLMi) and using currently Jaunty. Apart from the internal NIC (eth0), for internet I use a network interface via usb (it's a kingston port duplicator with some extra USB connections, so I get "all-usb-in-one-connection"), and it's eth1. When using NM (Network Manager), and without any hibernation, etc in between, when the dhcp lease expires, NM seems to ignore. These are the last logs about this:

Aug 24 20:03:28 oscar-laptop dhclient: DHCPREQUEST of 192.168.1.33 on eth1 to 192.168.1.1 port 67
Aug 24 20:03:28 oscar-laptop dhclient: DHCPACK of 192.168.1.33 from 192.168.1.1
Aug 24 20:03:28 oscar-laptop dhclient: bound to 192.168.1.33 -- renewal in 40125 seconds.
Aug 24 20:03:28 oscar-laptop NetworkManager: <info> DHCP: device eth1 state changed bound -> renew
Aug 24 20:03:28 oscar-laptop NetworkManager: <info> address 192.168.1.33
Aug 24 20:03:28 oscar-laptop NetworkManager: <info> prefix 24 (255.255.255.0)
Aug 24 20:03:28 oscar-laptop NetworkManager: <info> gateway 192.168.1.1
Aug 24 20:03:28 oscar-laptop NetworkManager: <info> nameserver '80.58.61.250'
Aug 24 20:03:28 oscar-laptop NetworkManager: <info> nameserver '80.58.61.254'

Which means that dhclient is aware of renewing and seems to renew properly. The leases are registered in the lease file:

# cat /var/lib/dhcp3/dhclient-eth1.lease
lease {
  interface "eth1";
  fixed-address 192.168.1.33;
  option subnet-mask 255.255.255.0;
  option routers 192.168.1.1;
  option dhcp-lease-time 86400;
  option dhcp-message-type 5;
  option domain-name-servers 80.58.61.250,80.58.61.254;
  option dhcp-server-identifier 192.168.1.1;
  renew 1 2009/08/24 18:03:28;
  rebind 2 2009/08/25 04:32:44;
  expire 2 2009/08/25 07:32:44;
}
lease {
  interface "eth1";
  fixed-address 192.168.1.33;
  option subnet-mask 255.255.255.0;
  option routers 192.168.1.1;
  option dhcp-lease-time 86400;
  option dhcp-message-type 5;
  option domain-name-servers 80.58.61.250,80.58.61.254;
  option dhcp-server-identifier 192.168.1.1;
  renew 2 2009/08/25 05:12:13;
  rebind 2 2009/08/25 15:03:28;
  expire 2 2009/08/25 18:03:28;
}

As a comment, though eth1 seems correctly configured, I'm not able to ping the gateway, and anything related to eth1 times out (dhclient, mii-tool,...)

I've been unable to renew via restarting NM nor "dhclient eth1". After trying any of these, all routes are lost. The only way I've found to renew the IP is to unplug and plug again the usb interface.

If this is a duplicate or I should open a new different bug, please let me know.

Revision history for this message
Dominique Unruh (unruh-mmci) wrote :

I changed the state to Confirmed by accident. I have no idea how to change it back. Sorry.

Changed in network-manager (Ubuntu):
status: Triaged → Confirmed
Changed in network-manager:
importance: Unknown → Wishlist
Olivier Mehani (shtrom)
Changed in network-manager (Debian):
importance: Undecided → Unknown
status: New → Unknown
Changed in network-manager (Debian):
status: Unknown → Confirmed
Changed in network-manager:
status: Confirmed → Fix Released
Thomas Hood (jdthood)
summary: - Network Manager should retry DHCP
+ NetworkManager does not retry DHCP after DHCP timed out once
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.