Re: NM does not work with iwl4965 device



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]