Description of problem: When switching from wired to wireless by clicking in networks list in applet, NM first takes down IP address from wired interface, then tries to connect to wifi. So there is a window of time when computer has no IP address and no connectivity thus. This is fatal when user's home directory is mounted by NFS. When wifi network need authentication, NM-applet window with quiestion appears and some gconf action (reading or writing) is performed. As NFS mount is unavailable (remember, no IP address), window freezes. Also, X11 dislikes disappering IP addresses, as authorisation is somehow based on them. How reproducible: Always. Steps to Reproduce: 1. Log on as user with home on NFS mount. NFS server should be accessible by wired and wireless networks. 2. Change to unknown wifi networks requiring authorisation. 3. (NM removes IP address from wired interface and tries to authorise and obtain address from wifi network) Actual results: Window displayed by NM freezes. Expected results: NM should remove IP address from wired interface AFTER it successfully obtained connectivity (including IP address) from wireless network. Additional info: Workaround when nm-applet window freezes: switch to console, login as root, restore wired interface IP address, switch back to X, enter credentials to connect to wifi network, let NM-applet remember those; after succesful connect switch to console and remove IP address from wired interface
I see this issue with the latest rawhide too.
I would hope that this would be possible with new multiple device support, however, the nature of NFS is such that it can't really take an advantage of NM as designed. NM is best for gracefully handling use cases outside of its control (random pull-out of the network cable, moving outside of APs range, etc.) However, for this to work, application/service needs to play nice, and be ready to lose network at any point in time. Many do so quite well already, from evolution to cupsd. NFS is quite bad in that area (justifiably so, one might argue), and NFS mounted home is the case where you wish you can somehow lock the cable to the socket. However, I would argue that pushing NM in that direction, to require explicit signaling before removing network device (which I see as the real solution to your problem, once the reported behavior is fixed) would be wrong for many other cases. However, a non-default option for that might suffice.
In case you care, there's a bug in b.g.o too: http://bugzilla.gnome.org/show_bug.cgi?id=384971
ad #2 In this case the same NFS server is accessible by wired and by wifi.
*** This bug has been marked as a duplicate of 178276 ***