Re: NM does not work with iwl4965 device
- From: Dan Williams <dcbw redhat com>
- To: Thomas M Steenholdt <tmus tmus dk>
- Cc: networkmanager-list gnome org
- Subject: Re: NM does not work with iwl4965 device
- Date: Wed, 08 Aug 2007 07:34:47 -0400
On Tue, 2007-08-07 at 00:28 -0200, Thomas M Steenholdt wrote:
> Thomas M Steenholdt wrote:
> >
> > I'll force it to use 1 or 2 this evening, and see what kind of success
> > that will give me.
> >
> > I'll keep you guys posted.
> >
>
> I've been experimenting a bit tonight and this is what I've found.
>
> AP_SCAN 2 : ESSID is set on the wireless device, but it never
> associates. Presumably because it cannot find the AP.
>
> AP_SCAN 1: ESSID does NOT get set on the wireless device, so does not
> work alone - during the device setup phase, if you issue an "iwconfig
> wlan0 essid whatever", the device will associate fine.
So the problem with this patch is that it doesn't actually take account
of what AP_SCAN values actually do... That said, AP_SCAN is _horrible_
and reflects wpa_supplicant assuming too much about what it should be
doing.
# 1: wpa_supplicant initiates scanning and AP selection
# 0: driver takes care of scanning, AP selection, and IEEE 802.11 association
# parameters (e.g., WPA IE generation); this mode can also be used with
# non-WPA drivers when using IEEE 802.1X mode; do not try to associate with
# APs (i.e., external program needs to control association). This mode must
# also be used when using wired Ethernet drivers.
# 2: like 0, but associate with APs using security policy and SSID (but not
# BSSID); this can be used, e.g., with ndiswrapper and NDIS drivers to
# enable operation with hidden SSIDs and optimized roaming; in this mode,
# the network blocks in the configuration file are tried one by one until
# the driver reports successful association; each network block should have
# explicit security policy (i.e., only one option in the lists) for
# key_mgmt, pairwise, group, proto variables
We never use 0, because that's only for wired.
1 means wpa_supplicant scans around and tries to find the AP. But if
the AP is "hidden", wpa_supplicant won't find it because wpa_supplicant
doesn't know how to find hidden APs. NM works around that by caching
the BSSID after a successful connection, and when it finds that BSSID in
scan results, filling in the SSID.
2 means NM must fill out the config for the network completely, and
wpa_supplicant just blows those settings to the card and waits for the
association to succeed. This is most closely analogous to a lot of
'iwconfig' commands. Only in this mode can wpa_supplicant really
connect to a hidden network, because NM would have given wpa_supplicant
both SSID and BSSID.
So it's understandable why wpa_supplicant doesn't set the SSID on the
card when you give it AP_SCAN=1, because it can't _find_ that SSID in
scan results precisely because the SSID isn't broadcasting it's SSID.
In this case I'd more suspect driver issues. Or, you could try a
straight wpa_supplicant configuration with both AP_SCAN=1 and AP_SCAN=2
and see which one works, without NM in the picture.
Dan
> So I made a patch to incorporate the two and to prove a point. :)
>
> Please note, that this patch is intended to prove that the association
> to hidden IS possible, even with ipw4965 devices. The patch changes the
> AP_SCAN value for hidden networks and I have no clue as to what that
> will do for other wireless devices. Also, since I've not gotten
> acquainted to very much of the NetworkManager code, there might be
> better places to put some of these things. So it should at the very
> least be reviewed by someone more familiar with the code than myself.
> (there - the disclaimer is double the size of the patch itself ;-p)
>
> Try it out and let me know how it works for you.
>
> My testing was performed on Fedora 7 - 0.6.5 version of NetworkManager.
> Obviously 0.6.5 is also the version that this patch is most likely to
> apply to.
>
> Good luck. Patch below!
>
> /Thomas
>
> --- NetworkManager-0.6.5/src/nm-device-802-11-wireless.c.fix-hidden
> 2007-06-07 13:22:21.000000000 -0200
> +++ NetworkManager-0.6.5/src/nm-device-802-11-wireless.c 2007-08-07
> 00:14:29.000000000 -0200
> @@ -2838,13 +2838,19 @@
> || (caps & NM_802_11_CAP_PROTO_WPA2);
>
> /* Use "AP_SCAN 2" if:
> - * - The wireless network is non-broadcast or Ad-Hoc
> + * - The wireless network is Ad-Hoc
> * - The wireless driver does not support WPA (stupid drivers...)
> */
> is_adhoc = (nm_ap_get_mode(ap) == IW_MODE_ADHOC);
> - if (!nm_ap_get_broadcast (ap) || is_adhoc || !supports_wpa)
> + if (is_adhoc || !supports_wpa)
> ap_scan = "AP_SCAN 2";
>
> + /* Use "AP_SCAN 1" if:
> + * - The wireless network is non-broadcast
> + */
> + if (!nm_ap_get_broadcast (ap))
> + ap_scan = "AP_SCAN 1";
> +
> /* Tell wpa_supplicant that we'll do the scanning */
> if (!nm_utils_supplicant_request_with_check (ctrl, "OK", __func__,
> NULL, ap_scan))
> goto out;
> @@ -2877,6 +2883,14 @@
> */
> if (!nm_ap_get_broadcast (ap) && !is_adhoc)
> {
> + /*
> + * since using "AP_SCAN 1" for hidden networks, wpa_supplicant
> + * does not seem to bring the essid to the device anymore...
> + * perhaps this is a wpa_supplicant/wext/driver issue or perhaps this
> + * is simply how it is. We set the ESSID here for now.
> + */
> + nm_device_802_11_wireless_set_essid(self, essid);
> +
> if (!nm_utils_supplicant_request_with_check (ctrl, "OK", __func__, NULL,
> "SET_NETWORK %i scan_ssid 1", nwid))
> goto out;
>
> _______________________________________________
> NetworkManager-list mailing list
> NetworkManager-list gnome org
> http://mail.gnome.org/mailman/listinfo/networkmanager-list
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]