Bug 496286

Thanks for filling this bug. Can you please provide your /var/log/messages after a network outages when the NFS volumes are going to unmount? Thank you.

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

When I just reselect the wireless network I'm already connected to, for example...

Apr 17 18:43:48 macbook NetworkManager: <info>  (wlan0): device state change: 8 -> 3
Apr 17 18:43:48 macbook NetworkManager: <info>  (wlan0): deactivating device (reason: 0).
Apr 17 18:43:48 macbook NetworkManager: <info>  wlan0: canceled DHCP transaction, dhcp client pid 16295
Apr 17 18:43:48 macbook kernel: iwlagn: index 0 not used in uCode key table.
Apr 17 18:43:49 macbook NetworkManager: nm_system_add_ip4_vpn_gateway_route: assertion `parent_config != NULL' failed
Apr 17 18:43:49 macbook NetworkManager: <WARN>  check_one_route(): (wlan0) error -34 returned from rtnl_route_del(): Sucess#012
Apr 17 18:43:49 macbook openconnect[16336]: DTLS got write error 5. Falling back to SSL
Apr 17 18:43:49 macbook NetworkManager: <info>  Activation (wlan0) starting connection 'Auto Baythorne Wavelan'
Apr 17 18:43:49 macbook NetworkManager: <info>  (wlan0): device state change: 3 -> 4
Apr 17 18:43:49 macbook NetworkManager: <info>  Activation (wlan0) Stage 1 of 5 (Device Prepare) scheduled...
Apr 17 18:43:49 macbook NetworkManager: <info>  Activation (wlan0) Stage 1 of 5 (Device Prepare) started...
Apr 17 18:43:49 macbook NetworkManager: <info>  Activation (wlan0) Stage 2 of 5 (Device Configure) scheduled...
Apr 17 18:43:49 macbook NetworkManager: <info>  Activation (wlan0) Stage 1 of 5 (Device Prepare) complete.
Apr 17 18:43:49 macbook NetworkManager: <info>  (wlan0): supplicant connection state:  completed -> disconnected
Apr 17 18:43:49 macbook NetworkManager: <info>  (wlan0): supplicant connection state:  disconnected -> associated
Apr 17 18:43:49 macbook NetworkManager: <info>  (wlan0): supplicant connection state:  associated -> disconnected
Apr 17 18:43:49 macbook NetworkManager: <info>  Activation (wlan0) Stage 2 of 5 (Device Configure) starting...
Apr 17 18:43:49 macbook NetworkManager: <info>  (wlan0): device state change: 4 -> 5
Apr 17 18:43:49 macbook NetworkManager: <info>  Activation (wlan0/wireless): connection 'Auto Baythorne Wavelan' has security, and secrets exist.  No new secrets needed.
Apr 17 18:43:49 macbook NetworkManager: <info>  Config: added 'ssid' value 'Baythorne Wavelan'
Apr 17 18:43:49 macbook NetworkManager: <info>  Config: added 'scan_ssid' value '1'
Apr 17 18:43:49 macbook NetworkManager: <info>  Config: added 'key_mgmt' value 'NONE'
Apr 17 18:43:49 macbook NetworkManager: <info>  Config: added 'auth_alg' value 'OPEN'
Apr 17 18:43:49 macbook NetworkManager: <info>  Config: added 'wep_key0' value '<omitted>'
Apr 17 18:43:49 macbook NetworkManager: <info>  Config: added 'wep_tx_keyidx' value '0'
Apr 17 18:43:49 macbook NetworkManager: <info>  Activation (wlan0) Stage 2 of 5 (Device Configure) complete.
Apr 17 18:43:49 macbook NetworkManager: <info>  Config: set interface ap_scan to 1
Apr 17 18:43:50 macbook NetworkManager: <info>  (wlan0): supplicant connection state:  disconnected -> scanning
Apr 17 18:43:50 macbook NetworkManager: <info>  (wlan0): supplicant connection state:  scanning -> associating
Apr 17 18:43:50 macbook NetworkManager: <info>  (wlan0): supplicant connection state:  associating -> associated
Apr 17 18:43:50 macbook NetworkManager: <info>  (wlan0): supplicant connection state:  associated -> completed
Apr 17 18:43:50 macbook NetworkManager: <info>  Activation (wlan0/wireless) Stage 2 of 5 (Device Configure) successful.  Connected to wireless network 'Baythorne Wavelan'.
Apr 17 18:43:50 macbook NetworkManager: <info>  Activation (wlan0) Stage 3 of 5 (IP Configure Start) scheduled.
Apr 17 18:43:50 macbook NetworkManager: <info>  Activation (wlan0) Stage 3 of 5 (IP Configure Start) started...
Apr 17 18:43:50 macbook NetworkManager: <info>  (wlan0): device state change: 5 -> 7
Apr 17 18:43:50 macbook NetworkManager: <info>  Activation (wlan0) Beginning DHCP transaction.
Apr 17 18:43:50 macbook NetworkManager: <info>  dhclient started with pid 18652
Apr 17 18:43:50 macbook NetworkManager: <info>  Activation (wlan0) Stage 3 of 5 (IP Configure Start) complete.
Apr 17 18:43:50 macbook dhclient: Internet Systems Consortium DHCP Client 4.1.0
Apr 17 18:43:50 macbook dhclient: Copyright 2004-2008 Internet Systems Consortium.
Apr 17 18:43:50 macbook dhclient: All rights reserved.
Apr 17 18:43:50 macbook dhclient: For info, please visit http://www.isc.org/sw/dhcp/
Apr 17 18:43:50 macbook dhclient: 
Apr 17 18:43:50 macbook NetworkManager: <info>  DHCP: device wlan0 state changed normal exit -> preinit
Apr 17 18:43:50 macbook dhclient: Listening on LPF/wlan0/00:16:ea:05:bb:b8
Apr 17 18:43:50 macbook dhclient: Sending on   LPF/wlan0/00:16:ea:05:bb:b8
Apr 17 18:43:50 macbook dhclient: Sending on   Socket/fallback
Apr 17 18:43:50 macbook dhclient: DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 6
Apr 17 18:43:50 macbook dhclient: DHCPOFFER from 81.187.2.163
Apr 17 18:43:50 macbook dhclient: DHCPREQUEST on wlan0 to 255.255.255.255 port 67
Apr 17 18:43:50 macbook dhclient: DHCPACK from 81.187.2.163
Apr 17 18:43:50 macbook dhclient: bound to 90.155.92.212 -- renewal in 33059 seconds.
Apr 17 18:43:50 macbook NetworkManager: <info>  DHCP: device wlan0 state changed preinit -> bound
Apr 17 18:43:50 macbook NetworkManager: <info>  Activation (wlan0) Stage 4 of 5 (IP Configure Get) scheduled...
Apr 17 18:43:50 macbook NetworkManager: <info>  Activation (wlan0) Stage 4 of 5 (IP Configure Get) started...
Apr 17 18:43:50 macbook NetworkManager: <info>    address 90.155.92.212
Apr 17 18:43:50 macbook NetworkManager: <info>    prefix 26 (255.255.255.192)
Apr 17 18:43:50 macbook NetworkManager: <info>    gateway 90.155.92.193
Apr 17 18:43:50 macbook NetworkManager: <info>    nameserver '90.155.92.195'
Apr 17 18:43:50 macbook NetworkManager: <info>    nameserver '90.155.92.194'
Apr 17 18:43:50 macbook NetworkManager: <info>    domain name 'infradead.org'
Apr 17 18:43:50 macbook NetworkManager: <info>  Activation (wlan0) Stage 5 of 5 (IP Configure Commit) scheduled...
Apr 17 18:43:50 macbook NetworkManager: <info>  Activation (wlan0) Stage 4 of 5 (IP Configure Get) complete.
Apr 17 18:43:50 macbook NetworkManager: <info>  Activation (wlan0) Stage 5 of 5 (IP Configure Commit) started...
Apr 17 18:43:51 macbook NetworkManager: <info>  (wlan0): device state change: 7 -> 8
Apr 17 18:43:51 macbook NetworkManager: <info>  Policy set 'Auto Baythorne Wavelan' (wlan0) as default for routing and DNS.
Apr 17 18:43:51 macbook NetworkManager: <info>  Activation (wlan0) successful, device activated.
Apr 17 18:43:51 macbook NetworkManager: <info>  Activation (wlan0) Stage 5 of 5 (IP Configure Commit) complete.
Apr 17 18:43:51 macbook ntpd[2694]: Deleting interface #13 vpn0, 143.185.76.218#123, interface stats: received=0, sent=0, dropped=0, active_time=5587 secs

This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle.
Changing version to '11'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

So the problem here is likely that autofs has a dispatcher script that tears down NFS when NM says the connection is down.  Not quite sure what to do here; there's clearly value in letting apps know the state of the connection, and that includes the actual state of the device.

But there's also value in having stuff like NFS or SSH or whatever survive a reconnect when the same IP address can be re-acquired within a small amount of time.

(In reply to comment #4)
> But there's also value in having stuff like NFS or SSH or whatever survive a
> reconnect when the same IP address can be re-acquired within a small amount of
> time.  

To a first-order approximation, it seems like what is desired here is just a
grace period during which NetworkManager will ignore a disconnect event
assuming that our address doesn't change. Correct? It seems like this would be
fairly easy to implement and gives us exactly the type of robustness that we're
looking for.

"fairly easy" isn't necessarily accurate :)

But for Fedora 12, when the carrier drops, NM will currently allow about 4 seconds for the carrier to be re-acquired before deciding to tear down the connection.  Maybe we need to take that up a bit, but...

There's a fundamental conflict between the case you're looking for and the case of a user actually pulling out the cable from the laptop or undocking.  NFS users are expecting to have seamless recovery after even a fairly long dropout.  Laptop users are expecting to quickly switch to wifi or 3G or some other connection method.  The more you up the carrier-off latency, the worse the case gets for laptop users.  The lower the carrier-off latency, the worse the experience is for frequent network dropouts for NFS users.

There's also link negotiation latency, sometimes 1Gb ethernet takes quite a while to establish a link, so we might want to tune the carrier latency based on the last link speed of the ethernet.

There's a few things we can do, but there's also some things that need more thought, since adding toggles or checkboxes all over the place is rarely the right thing to do.

This message is a reminder that Fedora 12 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 12.  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 '12'.

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 12'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 12 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

Fedora 12 changed to end-of-life (EOL) status on 2010-12-02. Fedora 12 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.