Description of problem: A small machine with runing installed "from scratch" Fedora 10 and with two network interfaces: eth0 (ONBOOT=yes) and wireless wlan0 (ONBOOT=no). Both interfaces are controlled by NetworkManager. With gdm showing up a login screen this gets a connection on a wired eth0 interface and this is good. Now logging into a desktop session on a user account may have the following outcomes: - a wired connection is "forgotten", even if in use by some remote login, and nm-applet announces, after long spinning, that a wireless connection was established - both connections are eventually up in parallel but this takes a while; that seems to be the most frequent result - only wired connection stays up (on really rare occasions) Unplugging in this moment a cable and replugging it again immediately brings a notification that a connection through eth0 is up but if wlan0 was active it will stay that way (most likely?). The only way to really drop wireless is to disable it on an nm-applet menu but enabling it causes attempts to connect to wireless again even if wired connection is up and in use. Is this intended? That with network information panels claiming 100 Mb/sec speed for wired and 1 Mb/sec for wireless. The last number, with scp reporting transfer speeds of an order of 2.8 MB/sec with a network cable disconnected, not really believable even if iwconfig really does say that. :-) 'iwlist wlan0 rate' comes back with wlan0 unknown bit-rate information. Current Bit Rate=1 Mb/s so that "1 Mb/s" can be some fallback not to report null. Version-Release number of selected component (if applicable): NetworkManager-0.7.0-1.git20090102.fc10.i386 How reproducible: see above Additional info: This is Atheros wifi hardware with ath9k driver.
(In reply to comment #0) > Description of problem: > > A small machine with runing installed "from scratch" Fedora 10 and with two > network interfaces: eth0 (ONBOOT=yes) and wireless wlan0 (ONBOOT=no). Both > interfaces are controlled by NetworkManager. > > With gdm showing up a login screen this gets a connection on a wired eth0 > interface and this is good. Now logging into a desktop session on a user > account may have the following outcomes: > - a wired connection is "forgotten", even if in use by some remote login, and > nm-applet announces, after long spinning, that a wireless connection was > established This sounds like the 'network' service is active. Can you check the output of: /sbin/chkconfig --list | grep network and see if any of the levels are "on"? > - both connections are eventually up in parallel but this takes a while; that > seems to be the most frequent result It's expected that any available interface will be brought up if the connection is marked "Connect automatically" in the connection editor, or ONBOOT=yes in the ifcfg file. > - only wired connection stays up (on really rare occasions) This is usually due to driver disconnections and driver inability to reconnect within a specified timeout period. However, there will be future workarounds to NetworkManager to alleviate this issue and smooth over some driver issues. > Unplugging in this moment a cable and replugging it again immediately brings a > notification that a connection through eth0 is up but if wlan0 was active it > will stay that way (most likely?). Not sure what you mean here. Can you explain a bit more? > The only way to really drop wireless is to disable it on an nm-applet menu but > enabling it causes attempts to connect to wireless again even if wired > connection is up and in use. Is this intended? That with network information Yes, if the connections are supposed to be autoconnected they will be brought up as they become available (ie, when the cable is plugged in or the wifi network is found). You can control them manually by making them not 'autoconnect'. > panels claiming 100 Mb/sec speed for wired and 1 Mb/sec for wireless. The last > number, with scp reporting transfer speeds of an order of 2.8 MB/sec with a > network cable disconnected, not really believable even if iwconfig really does > say that. :-) Speed sounds like a bug, though what you describe below makes it seem like the bug is in the driver, not NetworkManager. Both NM and 'iwconfig'/'iwlist' get their information from the same place: the driver. > 'iwlist wlan0 rate' comes back with > > wlan0 unknown bit-rate information. > Current Bit Rate=1 Mb/s > > so that "1 Mb/s" can be some fallback not to report null. Should probably report this as a kernel bug. Dan
> This sounds like the 'network' service is active. No, not really. # chkconfig --list network network 0:off 1:off 2:off 3:off 4:off 5:off 6:off and besides none of interface configuration files has 'NM_CONTROLLED=no' so, from I was told on another occasions, they should be ignored by network service even if it would be running. Like I said eth0 is marked ONBOOT=yes and wlan0 with ONBOOT=no. > It's expected that any available interface will be brought up if ... At least in older distros plugging in a wire had an effect of switching to it and disconnecting wireless. My experience with that is limited though to one another laptop using originally madwifi and later ath5k driver. >> Unplugging in this moment a cable and replugging it again immediately brings a >> notification that a connection through eth0 is up but if wlan0 was active it >> will stay that way (most likely?). > Not sure what you mean here. Can you explain a bit more? More or less what I said. Lets try a bit differently. A machine is running and a wired, only, connection is up brought up on a gdm level. Now you are starting a user session. nm-applet gets very busy and after a while says that I am on a wireless link. A wired connection may be still there or not. Now if I will take a network cable out and immediately in then I see right away "you are on eth0 ... (whatever)" popup and nm-icon shows a picture of two monitors. Sounds better? With that another laptop I had to unplug a wire before NM was starting attempts to connect on a wifi link. OTOH I never managed it to get a connection without somebody logged on a desktop and an upgrade from F8 to F10 did not change anything. Similar on my another "test" installation which went through the same upgrade. I still have to try to look closer at those bits. >> 'iwlist wlan0 rate' comes back with ... .... > Should probably report this as a kernel bug. OK. Will do.
Once I killed a constant stream of "ForceXPAon: 0" (bug 480429) then I can see in my logs something like and that while connected on a cable: ..... Jan 22 20:43:26 reddwarf NetworkManager: <info> (wlan0): supplicant connection state: completed -> disconnected Jan 22 20:43:26 reddwarf NetworkManager: <info> (wlan0): supplicant connection state: disconnected -> scanning Jan 22 20:43:27 reddwarf NetworkManager: <info> (wlan0): supplicant connection state: scanning -> associated Jan 22 20:43:28 reddwarf NetworkManager: <info> (wlan0): supplicant connection state: associated -> 4-way handshake Jan 22 20:43:28 reddwarf NetworkManager: <info> (wlan0): supplicant connection state: 4-way handshake -> group handshake Jan 22 20:43:28 reddwarf NetworkManager: <info> (wlan0): supplicant connection state: group handshake -> completed Jan 22 20:45:26 reddwarf NetworkManager: <info> (wlan0): supplicant connection state: completed -> disconnected Jan 22 20:45:26 reddwarf NetworkManager: <info> (wlan0): supplicant connection state: disconnected -> scanning Jan 22 20:45:27 reddwarf NetworkManager: <info> (wlan0): supplicant connection state: scanning -> associated Jan 22 20:45:28 reddwarf NetworkManager: <info> (wlan0): supplicant connection state: associated -> 4-way handshake Jan 22 20:45:28 reddwarf NetworkManager: <info> (wlan0): supplicant connection state: 4-way handshake -> group handshake Jan 22 20:45:28 reddwarf NetworkManager: <info> (wlan0): supplicant connection state: group handshake -> completed Jan 22 20:47:26 reddwarf NetworkManager: <info> (wlan0): supplicant connection state: completed -> disconnected Jan 22 20:47:26 reddwarf NetworkManager: <info> (wlan0): supplicant connection state: disconnected -> scanning Jan 22 20:47:27 reddwarf NetworkManager: <info> (wlan0): supplicant connection state: scanning -> associated Jan 22 20:47:28 reddwarf NetworkManager: <info> (wlan0): supplicant connection state: associated -> 4-way handshake Jan 22 20:47:28 reddwarf NetworkManager: <info> (wlan0): supplicant connection state: 4-way handshake -> group handshake Jan 22 20:47:28 reddwarf NetworkManager: <info> (wlan0): supplicant connection state: group handshake -> completed .... Does this may have something to do with the original issues? So far I did not manage rfkill keyboard switch to work. That would likely help but currently there is no reaction.
No, the supplicant connection messages don't have anything to do with the original issue. The GUI indications and applet behavior sound normal to me. It's expected that NM will bring up connections as they become available, if the connections are supposed to be autoconnected. It sounds to me like you've got a user-level connection for your wifi card that's autoconnect. Can you jump into the connection editor (right-click on the applet icon, choose Edit connections...) and click the Wireless tab, and see if there's more than one connection for your AP? Can you paste in the ifcfg file for your wifi connection? Basically, if the ifcfg-wlan0 file is a valid config, and it has ONBOOT=no set, then NM should be autoconnecting to it *unless* there's a user-level connection for it too. To verify the config, can you do the following, all as root? 1) service NetworkManager stop 2) killall -TERM nm-system-settings 3) /usr/sbin/nm-system-settings --debug --plugins=ifcfg-rh And paste the output back into this bug. Thanks!
> see if there's more than one connection for your AP At this moment this machine did not travel anywhere yet and there is only one connection present there, marked "Auto", to my home AP. > Basically, if the ifcfg-wlan0 file is a valid config, and it has ONBOOT=no set, > then NM should be autoconnecting to it *unless* there's a user-level connection > for it too. I have to admit that I am not sure how to understand the above. :-) > Can you paste in the ifcfg file for your wifi connection # Atheros Communications Inc. Unknown (0x002a) DEVICE=wlan0 HWADDR=00:22:43:60:f3:fb ONBOOT=no SEARCH="some.thing" None of the above I filled manually. BTW - this SEARCH information looks like misplaced here as it statically ties that up to some specific network. Most likely the one on which an installation was performed and that may have nothing to do even with a "home" network for this interface not mentioning all these other ones which it will be connecting too while wandering around. # /usr/sbin/nm-system-settings --debug --plugins=ifcfg-rh ** Message: Loaded plugin ifcfg-rh: (c) 2007 - 2008 Red Hat, Inc. To report bugs please use the NetworkManager mailing list. ** Message: ifcfg-rh: parsing /etc/sysconfig/network-scripts/ifcfg-eth0 ... ** Message: ifcfg-rh: read connection 'System eth0' ** Message: ifcfg-rh: parsing /etc/sysconfig/network-scripts/ifcfg-wlan0 ... ** Message: ifcfg-rh: error: Missing SSID ** Message: ifcfg-rh: parsing /etc/sysconfig/network-scripts/ifcfg-lo ... ** Message: ifcfg-rh: error: Ignoring loopback device config. Once again - "error: Missing SSID" seems like misplaced here. Or it wants some SSID for a wlan0 interface and not AP? The later will be changing all the time. In any case - with the current kernel the situation basically become predictable. Both interfaces will be up if only possible. Maybe these were some timeouts in play? Now both connections seem to come faster. OTOH unplugging a cable and plugging it back always was causing a practically instantenous reaction.
The "missing SSID" thing is the problem for your system wlan0 connection. ifcfg files are actually per *connection*, not per-interface. I can definitely have two ifcfg files like so: ifcfg-Home -------------- DEVICE=wlan0 TYPE=Wireless SSID=my-home ONBOOT=yes ifcfg-Work -------------- DEVICE=wlan0 TYPE=Wireless SSID=workplace-wifi ONBOOT=no In NetworkManager, this would show two system connections, and NetworkManager would automatically attempt to connect to the "Home" wifi (even before login) whenever the AP "my-home" was in range, because ONBOOT=yes. But it would only connect to the "workplace-wifi" when you tell it to manually, because ONBOOT=no. I think you can actually get rid of your ifcfg-wlan0 completely. That won't change any behavior from what you have now though. In any case, looks like the problem has either gone away or been fixed. Please re-open if it comes back. Thanks!
> The "missing SSID" thing is the problem for your system wlan0 connection. In that case this is a problem for NM; with which it can obviously cope but still. > ifcfg files are actually per *connection*, not per-interface. I can definitely > have two ifcfg files Yes, but this is one *connection* - with a dynamic configuration. I did use network profiles and implied in that multiple configuration files for *static* parameters connection. Are you trying to say that when travelling I have to create a separate ifcfg-... file for every Internet cafe, hotel, airport lounge, whatever? As of recently around here I can go to a Safeway store and get a free wifi connection from there. So you think that I would need a separate ifcfg for every Safeway store in the area or any other one I can possibly visit? You cannot be serious!
I got hit by the issue as described in the original report again. With one wired and one wifi, both handled by NM, it appears that this is a wired interface which "normally" gets forgotten on a login to a desktop session. It seems to happen infrequently, at least now while originally that it was quite easy to get there, and I have no idea how to possibly reproduce that other than by trying many times. Unplugging and replugging a network cable brings that interface immediately back. So this is more of a minor annoyance than a show-stopper. But yes, I did check in a "Connection information" panel and before that cable dance only a wireless was listed and I know that on a gdm screen eth0 was there and working. Due to all of the above I am not going to reopen this but maybe it should be?