Bug 481033 - NetworkManager interface choices unpredictable
NetworkManager interface choices unpredictable
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: NetworkManager (Show other bugs)
10
All Linux
low Severity medium
: ---
: ---
Assigned To: Dan Williams
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-01-21 15:39 EST by Michal Jaegermann
Modified: 2009-02-14 18:01 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-02-05 13:12:28 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Michal Jaegermann 2009-01-21 15:39:53 EST
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.
Comment 1 Dan Williams 2009-01-22 10:48:50 EST
(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
Comment 2 Michal Jaegermann 2009-01-22 16:53:23 EST
> 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.
Comment 3 Michal Jaegermann 2009-01-22 22:58:42 EST
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.
Comment 4 Dan Williams 2009-02-05 06:43:36 EST
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!
Comment 5 Michal Jaegermann 2009-02-05 12:59:30 EST
> 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.
Comment 6 Dan Williams 2009-02-05 13:12:28 EST
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!
Comment 7 Michal Jaegermann 2009-02-05 13:39:34 EST
> 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!
Comment 8 Michal Jaegermann 2009-02-14 18:01:14 EST
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?

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