"Too many aps breaks wpa_supplicant"

[Jim Veneskey]

Hi,
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?

Our lab probably has a thousand different BSSIDs all beaconing at once -

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 config is pretty simple:

# This line enables the use of wpa_cli which is used by rc.wireless
# if possible (to check for successful association)
ctrl_interface=/var/run/wpa_supplicant
# By default, only root (group 0) may use wpa_cli
ctrl_interface_group=0
eapol_version=1
ap_scan=2
fast_reauth=1
#country=US

# WPA protected network, supply your own ESSID and WPAPSK here:
network={
scan_ssid=1
ssid="linuxpsk"
proto=WPA RSN
key_mgmt=WPA-PSK
pairwise=CCMP TKIP
group=CCMP TKIP WEP104 WEP40
psk="somethingsecret"
priority=10
}

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.

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.

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

I appreciate any advice,

thanks

Jim

[Jouni Malinen]

Post by Jim Veneskey
I am attempting to use wpa_supplicant in one of our wireless testing
labs here at Cisco, and I am running into
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.

Post by Jim Veneskey
Our lab probably has a thousand different BSSIDs all beaconing at once -

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.

Post by Jim Veneskey
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.

Post by Jim Veneskey
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 ;-).

Post by Jim Veneskey
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]

Post by Jouni Malinen
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.

Based on a quick test with 2000 APs in scan results, the nl80211 part
for this seemed to be able to handle the results, but the default BSS
table limit (200) inside wpa_supplicant will likely end up dropping
needed information. I made this limit now configurable
(bss_max_count=<limit>) which should allow wpa_supplicant to be used
even with huge number of APs in the scan results (assuming you don't
care about memory use).

As an optional mechanism, I also added a configuration item for
filtering scan results to only include the BSSes that have an SSID
matching with one of the configured networks. This can be enabled with
filter_ssids=1 in wpa_supplicant.conf.

Both of these alternatives seemed to be able to complete association
with -Dnl80211 in a test with 2000 APs. The changes are available in
the development tree (0.7.x) git repository.

[Jim Veneskey]

Hi,
I'd love to give this new development version a try - but have never
used 'git' before.
Could someone please tell me how to retrieve the latest development
build via git?
http://hostap.epitest.fi/cvs.html
Is not very clear - other than saying that it can be done ;-)
I just need the command line to use with 'git' and I'll hopefully be
rolling...

We actually have approximately 800 APs in our testing environment with
most of them beaconing with their
full complement of 16 BSSIDs each - so we have quite a few ;-)

My target clients will not be able to hear them all (luckily) but they
will be able to hear a lot...

Jim

Post by Jouni Malinen

Post by Jouni Malinen
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.

Based on a quick test with 2000 APs in scan results, the nl80211 part
for this seemed to be able to handle the results, but the default BSS
table limit (200) inside wpa_supplicant will likely end up dropping
needed information. I made this limit now configurable
(bss_max_count=<limit>) which should allow wpa_supplicant to be used
even with huge number of APs in the scan results (assuming you don't
care about memory use).
As an optional mechanism, I also added a configuration item for
filtering scan results to only include the BSSes that have an SSID
matching with one of the configured networks. This can be enabled with
filter_ssids=1 in wpa_supplicant.conf.
Both of these alternatives seemed to be able to complete association
with -Dnl80211 in a test with 2000 APs. The changes are available in
the development tree (0.7.x) git repository.

[Holger Schurig]

Step 1: install git, e.g. "apt-get install git-core"

Step 2: git clone git://w1.fi/srv/git/hostap.git

Inside the newly created hostap there's not only hostapd, but also
wpa_supplicant.



Other than that, the web is full of introductory material for git. Use your
favorite web search engine.

[Jim Veneskey]

Post by Holger Schurig
Step 1: install git, e.g. "apt-get install git-core"

Already compiled git from source on my slackware machine....

Post by Holger Schurig
Step 2: git clone git://w1.fi/srv/git/hostap.git
Inside the newly created hostap there's not only hostapd, but also
wpa_supplicant.

Ah - that's what I needed to know - I now have a copy :-)

Post by Holger Schurig
Other than that, the web is full of introductory material for git. Use your
favorite web search engine.

*sigh*

I just double checked:
http://hostap.epitest.fi/cvs.html

and the command line syntax was there - I was just not wide awake enough
earlier to see it I guess.

Sorry for the interruption ;-)

Jim

[Jouni Malinen]

Post by Jim Veneskey
We actually have approximately 800 APs in our testing environment
with most of them beaconing with their
full complement of 16 BSSIDs each - so we have quite a few ;-)
My target clients will not be able to hear them all (luckily) but
they will be able to hear a lot...

The main problem I had in my tests was that the scan dwell time was not
long enough to be able to receive and process all the Probe Response
frames on a single channel.. ;-) Other than that, I would expect the
current development snapshot to be able to handle 10000 BSSes in scan
results. Would be interesting to hear how that goes with real APs rather
than simulated setup, though.

[Jim Veneskey]

Hi,
well - I compiled the latest development version and gave it a try.
I was QUITE impressed at how quickly it latched onto my AP among all of
the other BSSIDs in my environment.
This is a major improvement over the build I was using previously :-)

Thanks for your help!

Jim

Post by Jouni Malinen

Post by Jim Veneskey
We actually have approximately 800 APs in our testing environment
with most of them beaconing with their
full complement of 16 BSSIDs each - so we have quite a few ;-)
My target clients will not be able to hear them all (luckily) but
they will be able to hear a lot...

The main problem I had in my tests was that the scan dwell time was not
long enough to be able to receive and process all the Probe Response
frames on a single channel.. ;-) Other than that, I would expect the
current development snapshot to be able to handle 10000 BSSes in scan
results. Would be interesting to hear how that goes with real APs rather
than simulated setup, though.

[Kalle Valo]

Post by Jouni Malinen

Post by Jouni Malinen
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.

Based on a quick test with 2000 APs in scan results

Just out of curiosity, are there any tools available which would make
it easy to artificially create 2000 APs? I guess injecting Probe
Responses with different ssids is enough, but I wouldn't want
implement that from scratch.

[Holger Schurig]

Post by Kalle Valo
Just out of curiosity, are there any tools available which would make
it easy to artificially create 2000 APs? I guess injecting Probe
Responses with different ssids is enough, but I wouldn't want
implement that from scratch.

http://www.blackalchemy.to/project/fakeap/

[Kalle Valo]

Post by Holger Schurig

Post by Kalle Valo
Just out of curiosity, are there any tools available which would make
it easy to artificially create 2000 APs? I guess injecting Probe
Responses with different ssids is enough, but I wouldn't want
implement that from scratch.

http://www.blackalchemy.to/project/fakeap/

Thanks. Otherwise looks good, but talks only about hostap. Any ideas
if it would work with mac80211?

[Holger Schurig]

Post by Kalle Valo

Post by Holger Schurig
http://www.blackalchemy.to/project/fakeap/

Thanks. Otherwise looks good, but talks only about hostap. Any ideas
if it would work with mac80211?

It talks about the hostap driver, not about hostapd, the daemon.

Remember, this tool is so old it was written when fullmac drivers where the
common thing. The tool injects management frames (probably beacons) with faked
SSIDs. At this time (and even now), this couldn't be done with orinoco_cs,
which was quite prominent then.

However, even then the hostap driver was available and here you could inject
management frames, which for example hostapd (not the driver the daemon!)
does.

So basically you can inject management frames with each driver hostapd works,
and that would include mac80211. The original source I pointed out can be a
reference.