after sleep, default route is gone

Bug #69892 reported by Tessa
6
Affects Status Importance Assigned to Milestone
acpi-support (Ubuntu)
Fix Released
Undecided
Unassigned
network-manager (Ubuntu)
Fix Released
Undecided
Unassigned

Bug Description

This is a new issue I'm seeing in Edgy, after waking from sleep mode (not hibernation) my default route is missing. Restarting networking (and therefor the dhcp client) fixes this, but it's annoying to restart networking every time I wake my system.

I'm not sure where the problem is actually occurring, but I'm more than happy to do any testing required to track it down.

Revision history for this message
Tessa (unit3) wrote :

As an addition to this, I'm discovering that the default route isn't instantly gone, but disappears somewhere in the neighborhood of 30 seconds after waking the system. This makes me suspect there's some script running after waking that's trying to be helpful and clears the default route.

Revision history for this message
Tessa (unit3) wrote :

Aha! It appears it's network-manager that's killing the routes. If I kill all background network-manager processes, the routes stay after waking from sleep mode.

Revision history for this message
Roel Groeneveld (roel-groeneveld) wrote :

Graeme, thanks for the heads up.
I can confirm this behaviour.

See my related forum post http://ubuntuforums.org/showthread.php?p=1712998#post1712998

Revision history for this message
Wolf Pusztay (wolf-pusztay) wrote :

I've had the same experience using Dapper and now Edgy

Revision history for this message
Scott Robinson (scott-ubuntu) wrote :

This is an issue with the acpi-support scripts, not NM. Also, I think it's by design.

Revision history for this message
Tessa (unit3) wrote :

By design? Obviously I'm missing something, since I can't see a scenario where you'd want to clear your routes after sleeping. ;)

In any case, after removing network-manager from my system, I'm not longer seeing this problem. Is it possible that installing network manager can trigger this issue, or that network manager has its own issue with sleeping?

Revision history for this message
Tessa (unit3) wrote :

Hmm, doing more digging, seems like the problem I've been seeing may be related to Bug 40125. Is there a confirmed additional issue with ACPI? Or is this bug a duplicate of 40125?

Revision history for this message
Scott Robinson (scott-ubuntu) wrote :

A "default route" being gone is different than not associating after resume. Perhaps you need to be clearer about your issue.

As a result of a suspend, the network interface is brought down and, when appropriate, the DHCP lease is released. This is normal and correct behavior.

After resuming from a suspend, NM will search the local APs and attempt to (re-)associate and retrieve a DHCP lease from the highest priority friendly.

No matter how you cut it, there is a timeframe where no '"default route" will exist. Does this clarify things for you? Can you clarify for us?

Revision history for this message
Tessa (unit3) wrote :

Ok, I now understand what happens with network-manager. However, I only have a single wired connection, and it must have been taking over 2 minutes to reaquire the DHCP lease, as I was invariably getting impatient after about a minute and restarting networking manually via the init scripts. Is there a reason why network-manager takes so long on wired connections?

As well, I assume this means there *is* a separate issue with the ACPI scripts dropping the default route? If so, I don't think I'm experiencing it, as without network-manager installed, my routes (and dhcp address) stay intact over a sleep/resume.

Revision history for this message
Tessa (unit3) wrote :

This seems to be fixed in Feisty beta. Not sure which package exactly what responsible or how it was fixed, but I no longer see this behaviour.

Changed in network-manager:
status: Unconfirmed → Fix Released
Changed in acpi-support:
status: Unconfirmed → Fix Released
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.