The function nm_device_deactivate contains
//* Clean up stuff, don't leave the card associated *//
*if* (nm_device_is_wireless (dev))
{
nm_device_set_essid (dev, *""*);
nm_device_set_enc_key (dev, NULL, NM_DEVICE_AUTH_METHOD_NONE);
nm_device_set_mode (dev, NETWORK_MODE_INFRA);
nm_wireless_set_scan_interval (dev->app_data, dev,
NM_WIRELESS_SCAN_INTERVAL_ACTIVE);
}
In my installation of NM I have changed nm_device_set_essid (dev, *""*)
to nm_device_set_essid (dev, *" "*) twice in NetworkManagerDevice.c for
the following reason.
The ipw2200-1.0.8 driver interprets the essid "" as ANY. Setting this
essid does not force the AP to disassociate. As an experiment, connect
to an AP, then plug in a wire to get a wired connection, then do
'iwconfig ethx'. When I do this I see that my AP is still associated.
Also, check with 'ethtool ethx'. Setting the essid to a single space
does work although this seems like a hack.
I have also modified the ethtool support in NetworkManagerDevice.c
creating a function 'ethtool_detect' that returns 1 if a link is
present, 0 if no link is present, and -1 if ethtool is not supported.
For wireless, 'link' means association.
When ethtool is supported, I use it in the function that tests for
association, and I also use it in the function that deals with DHCP
timeouts: if ethtool_detect returns 1 for a wireless, I assume the fault
is with the DHCP server and call nm_device_new_ip4_autoip_config.
There have been reports that ethtool can be fooled with ipw2200. I am
looking for AP configuration scenarios that will cause ethtool to give a
false positive response with ipw2200.
--
Bill Moss
Professor, Mathematical Sciences
Clemson University
_______________________________________________
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list
