Re: iwl3945 and WPA

[Pavel Roskin <proski@gnu.org>]

On Fri, 2008-06-13 at 22:22 +0200, Maciek Kaliszewski wrote:

> I've checked and 0.6.3 is latest development version of wpa_supplicant.
> > Try removing "scan_ssid=1".   Also try ESSID scanning in iwlist:
> > iwlist wlan0_rename scanning essid APTEKA
> >   
>  Removing scan_ssid doesn't help .
> 
> iwlist wlan0_rename scanning essid APTEKA
> 
> gives the same results like
> 
> iwlist wlan0_rename scanning
> and
> iwlist wlan0_rename scanning essid AAAA
> so driver ignores essid parameter

Well, if iwlist doesn't confuse the driver by "essid", neither should
wpa_supplicant.

> It looks like driver issue (driver is returning bogus data)

But why does iwlist display the same data correctly?  If iwlist can
parse it, wpa_supplicant should be able to parse it as well.

Google search for "Invalid freq in scan results" finds another such case
back in year 2004:
http://lists.shmoo.com/pipermail/hostap/2004-March/thread.html#6134

> there is no AP with BSSID 00:00:01:00:00:1d and hidden SSID in vicinity 
> . There is only one (my) AP in the range .

Of course.  It looks like the initial "00:00:01:00" is bogus and the
final "00:1d" is the beginning of the correct BSSID.

> Moreover p54pci.ko driver  (from the  same family  )  works  just fine 
> with  this  version  of  wpa_supplicant .
> Command line and config file I run wpa_supplicant with  is the same.

It may be an alignment issue.  Different drivers may include different
data, in different order.

I suggest that you debug wpa_supplicant, specifically
wpa_driver_wext_get_scan_results() in src/drivers/driver_wext.c.  Try
printing iwe->cmd and iwe->len before the switch.  And please move it to
the hostap list.  If there is anything definitely wrong with the driver,
then please let us know.

-- 
Regards,
Pavel Roskin