Red Hat Bugzilla – Bug 199536
wired IP is released too early
Last modified: 2008-02-12 09:09:24 EST
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.
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)
Window displayed by NM freezes.
NM should remove IP address from wired interface AFTER it successfully
obtained connectivity (including IP address) from wireless network.
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
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:
In this case the same NFS server is accessible by wired and by wifi.
*** This bug has been marked as a duplicate of 178276 ***