Bug 141677 - No auto failover
No auto failover
Product: Fedora
Classification: Fedora
Component: NetworkManager (Show other bugs)
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Dan Williams
Depends On:
  Show dependency treegraph
Reported: 2004-12-02 15:58 EST by David Hart
Modified: 2007-11-30 17:10 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-09-05 02:41:59 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description David Hart 2004-12-02 15:58:11 EST
1. Laptop with ETH0 and ATH0 (wireless). The wireless card funtions
perfectly with the MadWifi drivers.

2. Both interfaces are configured for DHCP.

3. HAL, DBUS and NM services are running. No errors.

4, Desktop=KDE

If I pull the plug on the ethernet card, my expectation is a
switchover to wireless. Nothing happens.

I have also tried the newer version of NM from Devel. Same result.
Comment 1 Dan Williams 2004-12-02 17:40:05 EST
What type & driver are your wired ethernet card?
Comment 2 David Hart 2004-12-02 18:10:49 EST
Ethernet controller: Silicon Integrated Systems [SiS] SiS900 PCI Fast
Ethernet (rev 90).

Driver = sis900
Comment 3 Satish Balay 2004-12-08 18:45:48 EST
Network manger doens't work for me as well with 'ath0' (madwifi) on a thinkpad.
I'm currently using NetworkManager-gnome-0.3.2-3.cvs20041117 from rawhide.

It does attempt to change to wireless (on disconnecting eth0 - e1000) - but it
can't find the network.

I attempt to manually specify the 'essid' - but it still can't find the network.
(this is with unencrypted) network. I get the message:

'The requested wireless netowrk 'SSID' does nt appear to be in range. ...'

I've also tried with an encrypted network (didn't work)

Looks like the same problem as the initial bugreport - hence tagging along
(otherwise I can open another bugzilla entry)
Comment 4 Satish Balay 2004-12-08 19:18:25 EST
BTW: I tired 'NetworkManager --no-daemon' - and tried setting ESSID from
'NetworkManagerInfo' - and I get the following:

NetworkManager: nm_device_activate_wireless(ath0): waiting for an access point.
NetworkManager: nm_hal_device_property_modified() called with udi =
/org/freedesktop/Hal/devices/pci_168c_12, key = net.interface_up, is_removed =
0, is_added = 0
NetworkManager: nm_hal_device_property_modified() called with udi =
/org/freedesktop/Hal/devices/pci_168c_12, key = net.interface_up, is_removed =
0, is_added = 0
NetworkManager: nm_device_wireless_activate(ath0) using essid 'MCS', with no
NetworkManager: HAVELINK: act=0
NetworkManager: nm_device_activate_wireless(ath0): no link to 'MCS', or couldn't
get configure interface for IP.  Trying another access point.
NetworkManager: nm_device_activate_wireless(ath0): waiting for an access point.
Comment 5 Dan Williams 2005-01-29 17:11:59 EST
Could you guys try with newer versions of NetworkManager &
NetworkManager-gnome that are in FC3-updates?

Comment 6 David Hart 2005-01-29 17:27:07 EST
I have tried the latest update and the more recent CVS. The tray
applet just spins indefinitely. The graphic is well done and quite
appealing if that's any consolation. Nevertheless, no failover to

I am going to create a new BZ because the newer versions introduce a
new problem which is the necessity of having Bind running. This is a
terrible waste of resources given that I have a dedicated Bind server
on the network (which is also locally authoritative). Moreover, it
overwrites resolv.conf without consent.

There is an option in the CVS to compile without bind support which
does not alleviate the issue.

Without bind running, NM senses if I pull the ethernet plug but does
nothing further. It does not sense when the ethernet connection is
Comment 7 Dan Williams 2005-01-29 17:32:01 EST
Current rawhide uses bind in a caching-nameserver situation.  This
will persist until we can get lwresd & nss_lwres functional.

FC3-updates version does _NOT_ use bind, with slightly reduced

There was also an FC-3 update to HAL that may fix the ethernet link
problem.  There was a bug in HAL that caused it to stop monitoring the
netlink socket for link status change events.

Comment 8 David Hart 2005-01-29 17:45:21 EST

I am assuming those are the update versions. If I'm a nitwit and got
it wrong, please advise.

This time, NM overwrote resolv.conf and left it blank.
No failover to ath when I pulled the eth0 plug.. 
Comment 9 Dan Williams 2005-01-29 18:03:56 EST
Confirmed, this is caused by a previous "feature" (ahem, hack) that
left an existing configured wired device up, but short-circuited the
DNS process.  That was removed in CVS on Jan 21, and should show up in
a further update for FC3.

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