Bug 494523 - NetworkManager takes evolution/firefox randomly offline
Summary: NetworkManager takes evolution/firefox randomly offline
Keywords:
Status: CLOSED DUPLICATE of bug 492147
Alias: None
Product: Fedora
Classification: Fedora
Component: NetworkManager
Version: 10
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: Dan Williams
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2009-04-07 10:13 UTC by Steve Whitehouse
Modified: 2009-04-11 11:29 UTC (History)
1 user (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2009-04-11 11:29:19 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Steve Whitehouse 2009-04-07 10:13:12 UTC
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.

Comment 1 Dan Williams 2009-04-09 01:12:28 UTC
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?

Comment 2 Steve Whitehouse 2009-04-09 08:04:46 UTC
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.

Comment 3 Dan Williams 2009-04-11 11:28:39 UTC
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.

Comment 4 Dan Williams 2009-04-11 11:29:19 UTC

*** This bug has been marked as a duplicate of bug 492147 ***


Note You need to log in before you can comment on or make changes to this bug.