Re: NM does not work with iwl4965 device

[Dan Williams <dcbw redhat com>]

On Wed, 2007-08-08 at 10:30 -0200, Thomas M Steenholdt wrote:
> Dan Williams wrote:
> > 
> > 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.
> > 
> .. snip ..
> > 
> > 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
> > 
> 
> As I mentiond, plain wpa_supplicant, iwconfig works fine for me. In my 
> wpa_supplicant.conf i don't even have an AP_SCAN option and as I see it, 
> wpa_supplicant uses a default of 1 in that case. I could be mistaken here.

Can you post the output of wpa_supplicant with the "-ddd" option please?
I'd love to see _why_ it works for you with a hidden network, because it
likely shouldn't.

dan

> NM uses AP_SCAN 2 for all hidden networks. If NM needs to fill in all 
> the info, including BSSID, for wpa_supplicant, then that's probably 
> exactly what fails. John W. Linville pointed out that there are some 
> issues with mac80211 pre-authentication scanning, making it unable to 
> see hidden networks.
> 
> AP_SCAN 2, in this case, just doesn't work (note: using my old 3945 
> device, I haven't had any problems like this for a long time). So 
> whether You think that the patch ignores the purpose of the AP_SCAN 
> values, using 1 and an SSID push to device makes it work better here :).
> 
> I'm not trying to "defend" the patch in any way, since it's clearly a 
> sort of "proof of concept" patch. It makes NM push AP_SCAN 1 to 
> wpa_supplicant and sets the SSID on the device in order to make the 
> association happen. As you point out, this is probably no the right(tm) 
> way to do this, but it makes wireless usable for me. AP_SCAN 1 also 
> seems less secure than 2, since it doesn't care about the BSSID to make 
> the association.
> 
> The right way to fix the problem as I see it, would probably be to get 
> the mac80211 pre-auth scanning working properly.
> 
> /Thomas
> 
> _______________________________________________
> NetworkManager-list mailing list
> NetworkManager-list gnome org
> http://mail.gnome.org/mailman/listinfo/networkmanager-list