"Too many aps breaks wpa_supplicant"

[Jouni Malinen]

On Fri, Mar 05, 2010 at 06:59:46AM -0500, Jim Veneskey wrote:
> I am attempting to use wpa_supplicant in one of our wireless testing
> labs here at Cisco,  and I am running into
> the issue discussed here:
> 
> http://lists.shmoo.com/pipermail/hostap/2008-May/017853.html
> 
> Was this ever resolved?

The wpa_supplicant side of it is more or less resolved, i.e.,
wpa_supplicant can handle the maximum length that Linux Wireless
Extensions support for reporting scan results. However, the kernel side
issues with mac80211/cfg80211-based drivers was not fixed for WEXT use
if I remember correctly.

> Our lab probably has a thousand different BSSIDs all beaconing at once -
> which is probably the reason why I keep seeing this:
> 
> > RTM_NEWLINK, IFLA_IFNAME: Interface 'ath0' added
> > Wireless event: cmd=0x8b19 len=8
> > Scan results did not fit - trying larger buffer (8192 bytes)
> > Scan results did not fit - trying larger buffer (16384 bytes)
> > Scan results did not fit - trying larger buffer (32768 bytes)
> > Scan results did not fit - trying larger buffer (65535 bytes)
> > ioctl[SIOCGIWSCAN]: Argument list too long
> > Failed to get scan results

My guess would be that this is indeed cfg80211 code hitting the WEXT
maximum buffer size and then not returning the value cleanly. I don't
know whether anyone would be interested enough to fix the WEXT compat
code at this point, though. I think I proposed a workaround for it, but
due to lack of interest did not really push to get it included in the
kernel.

I would suggest running a test with nl80211 (i.e., -Dnl80211 on
wpa_supplicant command line; and add CONFIG_DRIVER_NL80211=y into
.config for wpa_supplicant build configuration). If this does not work,
people are much more likely to get it fixed that with WEXT which is in
practice obsolete as far as any new features are considered and
end-of-life for most purposes from Linux development view point.


> I thought "ap_scan=2" was supposed to fix this issue, but I have been
> searching and searching and really can't
> find anything documenting just what "scan_ssid" and "ap_scan" are
> actually controlling.

ap_scan=2 would change the association process in a way that makes
wpa_supplicant only ask the driver to associate to a specific network
instead of first requesting scan results (which is the operation failing
in your particular test setup). However, mac80211-based drivers do not
support ap_scan=2 with WPA networks in practice..

scan_ssid=1 would request scans for a specific SSID to find hidden (no
SSID broadcast) network, but this is done only in addition to wildcard
scans, so it is unlikely to help here.

> Our windows and OSX boxes work flawlessly in this environment - they
> latch onto the correct BSSID instantly - but I'd
> really like to use wpa_supplicant since it would allow me to easily
> automate the configuration of the wireless networks for my clients.

At least Windows drivers use ap_scan=2 like behavior which reduced the
need to get the scan results.. Anyway, I'm interested in getting
wpa_supplicant/Linux combination working no matter how many APs you have
in the lab (assuming the channels are not completely full of Beacon
frames obviously ;-).

> I'm currently using the ath5k driver in kernel version 2.6.33

That should be new enough kernel version to allow nl80211 to be used. I
would suggest a test with wpa_supplicant 0.7.1 and -Dnl80211. If that
fails, please let me know and we'll figure out how to fix that one way
or another to avoid getting stuck with failed scan results fetching.

-- 
Jouni Malinen                                            PGP id EFC895FA