Red Hat Bugzilla – Bug 494523
NetworkManager takes evolution/firefox randomly offline
Last modified: 2009-04-11 07:29:19 EDT
Description of problem: I have a single network device with config as follows: [root@dolmen network-scripts]# cat ifcfg-wlan0 # Intel Corporation PRO/Wireless 3945ABG Network Connection DEVICE=wlan0 HWADDR=XX:XX:XX:XX:XX:XX (blanked for security) ONBOOT=no SEARCH="XXXXXXX" (blanked for security) BOOTPROTO=dhcp TYPE=Wireless USERCTL=no PEERDNS=yes IPV6INIT=no NM_CONTROLLED=no RATE=auto #MODE=Auto CHANNEL=6 KEY=s:XXXXXXXXXXX (blanked for security) which I manually set up when I want to use it. I noticed that both evolution and firefox would, when run after the network device was set up and working both appear in "offline" mode. At varying (so far as I can tell, random) periods, even though I'd manually set them into "online" mode, they would revert to offline mode, which is very annoying. Version-Release number of selected component (if applicable): Latest F-10 packages How reproducible: Every time Actual results: Firefox and evolution get put into offline mode on start up and at varying points in time after. Expected results: They should be in online mode. Additional info: The workaround is to disable NetworkManager by turning it off at boot. Since I did that, I haven't seen evolution or firefox being put into offline mode at any stage.
If you aren't using NetworkManager to control your primary network connection, then you probably want to disable it. If you were activating the connection manually underneath NM, then it's expected that NM wouldn't know about that connection (since NM didn't activate it) and thus firefox and pidgin wouldn't know either. What's the real bug here, that an *NM* controlled wifi connection is unstable? If so, can you attach some bits from /var/log/messages that show the disconnections, and from 'dmesg' showing why the driver is getting kicked off from your AP?
Yes, I did disable it in the end. I couldn't use NetworkManager to control the interface due to bz #448437. That bug didn't make things unstable but completely unusable. So the issue is with the single interface listed as not being controlled by NM, the various desktop apps get set into "offline" mode at seemingly random intervals. I can accept that they might come up on offline mode since MN thinks there is no external connection (although I don't understand why NM_CONTROLLED has to mean not monitored by NM as well as not controlled - surely these would be two different things?) but the issue is that NM shouldn't be randomly turning the apps into offline mode at a later points in time. After all, since NM isn't apparently monitoring any interfaces, what events might have occurred to make it set the apps offline? The wlan didn't change state at all, even under manual control in those cases. The issue is really that desktop apps shouldn't be sent messages from NM like this as it will confuse people. It took me a while to work out what was going on, so I'm sure that I will not be the only person to be confused - I dare say that a lot of people would report such issues against the apps themselves and not realise that NetworkManager is involved somehow.
It's pretty simple actually. If NM brings up an interface and gets a valid IP for that interface (static or DHCP) then you're "online". If NM can't bring up an interface, then you're not online. So, maybe you made NM ignore eth0, but at a later time NM was able to bring up wlan0? In that case, you'd have been "offline" until NM brought up wlan0 because you made NM ignore eth0. Again, if you make NM ignore an interface, then of course it's not going to know anything about that interface.
*** This bug has been marked as a duplicate of bug 492147 ***