On Tue, 2007-01-30 at 16:46 +1300, delgarde ihug co nz wrote:
> Dan Williams wrote:
> > If you can build your own copy of wpa_supplicant, put some
> > debugging prints in driver_wext.c in
> > wpa_driver_wext_get_scan_results() in the 'case
> > SIOCGIWESSID:' block to print out the code flow there.
> > What's 'ssid_len'? Does the 'if (custom + ssid_len >
> > end)' trigger?
>
> Will do. I'll also try using the same version of the
> supplicant with NM 0.6.4, see if the problem occurs there,
> see if it's the 0.5.7 supplicant in general, or just the
> D-Bus code.
Ok, I've done some experimenting, particularly on my currently working
system - NM 0.6.4, wpa_supplicant 0.5.7, and various recent madwifi
drivers. NM isn't crashing, but it looks like there might really be an
access point out there with a blank ESSID - it shows up in wlanconfig
(which shows it as 0x000000000), iwlist, and wpa_supplicant. NM doesn't
show it at all.
So, what does this suggest? Same versions of madwifi and wpa_supplicant,
NM 0.6.4 works and 0.7 doesn't? Does the 0.6.4 code that talked to the
supplicant do some kind of validation that 0.7 doesn't? Does 0.6.4 use
strlen() to get the length of the ESSID string, instead of having it
passed as a parameter?
If it offers any ideas, the iwlist command reports the odd AP as:
Cell 09 - Address: 00:40:96:37:3B:F4
ESSID:""
Mode:Master
Frequency:2.447 GHz (Channel 8)
Quality=3/94 Signal level=-92 dBm Noise level=-95 dBm
Encryption key:off
Bit Rates:1 Mb/s; 2 Mb/s; 5.5 Mb/s
Extra:bcn_int=100
Simon.
Attachment:
signature.asc
Description: This is a digitally signed message part