Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 454955 - When booting, both Wired and Wireless always activate
Summary: When booting, both Wired and Wireless always activate
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: NetworkManager
Version: 10
Hardware: i686
OS: Linux
low
low
Target Milestone: ---
Assignee: Dan Williams
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2008-07-11 01:26 UTC by Robert Locke
Modified: 2013-06-04 16:24 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2009-01-08 03:30:08 UTC


Attachments (Terms of Use)

Description Robert Locke 2008-07-11 01:26:36 UTC
Description of problem:
Following update, system now connects to both Wired & Wireless

Version-Release number of selected component (if applicable):
NetworkManager-0.7.0-0.6.9.svn3675.fc8

How reproducible:
Every time

Steps to Reproduce:
1. Applied update
2. Rebooted
  
Actual results:
System connected to both Wired and Wireless

Expected results:
System should pick optimal connection which is Wired

Additional info:
Both network-scripts/ifcfg-eth0 and ifcfg-wlan0 have
NM_CONTROLLED=yes
ONBOOT=no

IBM Thinkpad T60 with e1000e and iwl3945

Comment 1 Dan Williams 2008-07-18 17:38:45 UTC
NM 0.7 brings up all available connections that are marked "autoconnect".  So
it's normal that both wired and wireless should be up at the same time.  To
selectively disable this, you can turn off autoconnect on a
connection-by-connection basis.

What is likely a bug here is that since you have ONBOOT=no, that NM is
automatically bringing up those devices.  ONBOOT maps to autoconnect, so unless
you have previously defined user connections this shouldn't cause NM to connect.

Can you check in the connection editor whether you have user other connections
defined that could be causing the autoconnect behavior?  Right-click on the
applet, and choose "Edit connections...", and see in the wired and wireless tabs
if there are any connections that don't have "System" in front of them.  Try
deleting these connections, then reboot.

Comment 2 Robert Locke 2008-07-19 03:28:46 UTC
If I just left click nm-applet, I see "Auto Ethernet" (radio buttoned) and
"System eth0" (not radio buttoned) under Wired, and "ralii.com" (radio buttoned)
under Wireless.

If I right click nm-applet and choose Edit Connections..., I see "Auto Ethernet"
under Wired and "Auto ralii.com" and "Auto furguson" under Wireless.

So, now I am confused by your description as to how I make NM "choose" the best
connection to "auto connect" as it did in previous versions.

Scenario: basement has weak wireless (but visible), so I attach wire which it
uses. When allowed upstairs, I disconnect wire and while walking up the steps,
it switches to wireless.  At least this is what it "used to do".  Now, it
attaches to both wired and wireless while in basement.

Suggestions on what you want me to "change" to accomplish above?  Thanks!

Comment 3 Orion Poplawski 2008-09-02 18:26:56 UTC
I'm seeing the same (new) behavior - NM bringing up both the wired and wireless network - though in my case the wireless network is brought up at login because the wireless connections are defined per-user.  I see no way to be able to auto connect to both the wired and wireless network when the other is present but to only connect to the wired network when both are present.  How do I achieve that?

Comment 4 Nick Boldt 2008-11-07 19:33:43 UTC
I'd like this functionality too -- autoconnect to wired ONLY when both wired and wireless present. When wired disconnected, switch to wireless automagically. When wired reappears, switch to wired and disconnect wireless. 

The real reason I prefer this behaviour is that when I'm connected to my VPN and also running BOTH eth0 and wlan0, DNS never seems to resolve properly. Turning off the wireless (right-click NetworkManager Applet 0.7.0 icon > [ ] Enable Wireless) fixes all DNS resolution issues immediately. 

(That might be a separate bug.)

My hardware is a Lenovo Thinkpad X200; I'm running Fedora 9.9.3 (2.6.27.4-68.fc10.i686) from http://spins.fedoraproject.org/torrents//Fedora-10-Snap3-i686-Live-XFCE.torrent w/ latest rawhide updates.

Comment 5 Bug Zapper 2008-11-26 10:59:29 UTC
This message is a reminder that Fedora 8 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 8.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '8'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 8's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 8 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Comment 6 Nick Boldt 2008-11-26 15:34:34 UTC
Issue still exists in Fedora 10. Can you move this bug to "Version: 10" so it won't be automatically closed and ignored?

Comment 7 Dan Williams 2008-11-26 15:45:01 UTC
If the connections are 'autoconnect', then yes, NM will bring them up as the devices are available.  Unplug the ethernet cable, or disable wireless by flipping the rfkill switch, or turn autoconnect off on the connections, and NM won't connect that device until you explicitly tell it to do so.

Comment 8 Dan Williams 2008-11-26 15:45:49 UTC
It's expected behavior that, if you have autoconnect connections defined (or ONBOOT=yes in the ifcfg file) that the device will be brought up when it's able to be connected.

Comment 9 Robert Locke 2008-12-05 16:33:19 UTC
If this is "expected behavior", it is a regression.

NM "used to" prioritize wired over wireless and connect only one.

Is the idea of setting priorities for connections on the "drawing board"?

Comment 10 Dan Williams 2008-12-05 22:49:03 UTC
(In reply to comment #9)
> If this is "expected behavior", it is a regression.

no, it's not a regression; it's the same behavior that the network service has and that's what NetworkManager matches.

> NM "used to" prioritize wired over wireless and connect only one.

NM still does this; even if both are active, your wired interface is the "default" interface and traffic will flow through the wired interface.

> Is the idea of setting priorities for connections on the "drawing board"?

No, becuase they are already prioritized like they were before.

What *exactly* is your problem when both the wired and the wireless interfaces are up and active?  Is the traffic not going out the wired interface as you would expect?

Comment 11 Huzaifa S. Sidhpurwala 2008-12-10 09:22:10 UTC
Frankly speaking, i would like if wireless is disabled when wired is connected.
What is the logic is keeping both the interfaces up?

Comment 12 Dan Williams 2008-12-10 18:04:13 UTC
Minimizing latency of network switches when you disconnect or otherwise change the connections.  It's also necessary for multiple device support.  If you don't want multiple connections up and running at the same time, you're free to mark all your connections with autoconnect=false and control them manually just like ifup/ifdown, or to clean out access points you no longer connect to so that NM won't try to connect to them automatically.  There is no loss of functionality from having both interfaces up at the same time, and if you don't want wireless and wired up at the same time you can simply flip the killswitch or uncheck "Enable Wireless" from the menu.

Comment 13 Huzaifa S. Sidhpurwala 2008-12-11 03:38:04 UTC
There are three usability issues i see here:

1. If you have any wep encrypted wireless networks you have previously connected to, after logging, nm prompts the key ring password. As it tried to connect to those networks again.

2. Will it be safe to connect to unknown wireless networks at all. NM will try to connect to all available networks, We dont want to connect to hostile networks.

3. Would be a good idea to have a gui which will allow us to clear unused access points from gconf. The current method of using gconftool is anything but user friendly.

Comment 14 Dan Williams 2008-12-11 15:10:37 UTC
(In reply to comment #13)
> There are three usability issues i see here:
> 
> 1. If you have any wep encrypted wireless networks you have previously
> connected to, after logging, nm prompts the key ring password. As it tried to
> connect to those networks again.

pam_keyring; make sure your login password is the same as your keyring password, by using 'seahorse' to change the keyring password if you have updated your login password since you set your machine up.  Your keyring will be automatically unlocked when you log in.

> 2. Will it be safe to connect to unknown wireless networks at all. NM will try
> to connect to all available networks, We dont want to connect to hostile
> networks.

NM will *only ever* connect to a network that you have previously connected to.  It will never connect to random networks.  Thus, some user action is necessary before NM will connect to an unsecured network.  We can make this better in the future by defaulting to 'autoconnect=false' for unsecured networks and putting a notification bubble up saying "this network is insecure, please click here if you really want to automatically connect to it".

> 3. Would be a good idea to have a gui which will allow us to clear unused
> access points from gconf. The current method of using gconftool is anything but
> user friendly.

/usr/bin/nm-connection-editor, or right-click on the applet icon and choose "Edit connections...".

Comment 15 Charles R. Anderson 2009-01-08 03:30:08 UTC
I think the situation has been adequately explained by Dan Williams and there is no real bug here.  Closing.  FC8 is also EOL, so if you believe the functionality isn't working as Dan described, please open a new bug on a currently supported Fedora version.  Thanks.

Comment 16 Éric Brunet 2010-11-04 12:42:16 UTC
(In reply to comment #10)
> What *exactly* is your problem when both the wired and the wireless interfaces
> are up and active?  Is the traffic not going out the wired interface as you
> would expect?

Yes it does. I am sorry to come back to a two year old issue, but I find this behaviour strange. The main problem I see is:

the nm-applet icon indicates it tries to connect (to the wireless) while network is already up and running (through wired). Because of this I am waiting before launching my network app even though I have connectivity.

At the very least, the icon "connected through wired" should be prioritary over "trying to connect thorugh wireless".

By the way, once the useless wireless is configured, is there some extra power 
drawn to the wifi card compared to the situation where wireless is disabled ?
If so, it is an extra reason why nm-applet should'nt connect to both.

Comment 17 Karel Volný 2013-06-04 12:21:36 UTC
FYI, this has been brought up again in bug #970293
I was thinking about closing that as a duplicate and reopening this, but ... those interested, please follow the new bug

Comment 18 Dan Williams 2013-06-04 16:24:39 UTC
Icon/display issues are bugs for the UI applets, not NM core though, so that  means either the gnome-shell or network-manager-applet packages.


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