bss_max_count needed in real-world scenario

[Ben Greear]

On 07/11/2011 10:48 AM, Jouni Malinen wrote:
> On Mon, Jul 11, 2011 at 10:18:28AM -0700, Ben Greear wrote:
>> We had a user testing our wifi station emulator in a big, new
>> trade-show facility, and there were so many APs there that
>> supplicant would not associate.
>>
>> Turns out, we needed to set the bss_max_count to something
>> larger (we chose 2000).  Then it worked like a charm.
>
> How did you configure wpa_supplicant to connect to the network? With a
> configuration file that had a single network block with the SSID
> specified?

Yes.  We saw same behaviour with a single station as when running
64 virtual stations.

>> However, I suspect that many folks are not aware of this
>> setting and will be disappointed when they fire up their
>> Linux laptop in this building.  It is quite difficult
>> to debug what is going on...we mainly got lucky with a
>> google search to find this bss_max_count option.
>>
>> I'd suggest either making the bss-count larger by default,
>> able to grow dynamically, or at the very least, big loud
>> warning messages with suggested config changes in the
>> logs when there are more BSS's than can fit in the
>> current buffers.
>
> The BSS table itself is allocated one BSS at a time, so it can grow in
> size dynamically. The main reason for the string limit on the number of
> entries is to avoid unbounded memory use that would be quite unfortunate
> on many embedded designs and well, even on other devices since it would
> be trivial for an attacker to generate thousands of APs to fill memory..
> As such, I'm not sure that I would really like to increase the default
> value.
>
> I think that a better approach would be to make wpa_bss_add() more
> clever on which old entry to remove when adding a new one. If you have
> already configured a network (or multiple networks), it would be better
> to prefer to remove BSS entries that do not have a matching SSID instead
> of the one that was updated longest time ago. This should address the
> most realistic use cases without increasing memory use.

Ok, that sounds fine to me.  That would have probably fixed the
problem in this case, though they also had a very large number of
APs with same SSID.

I still think you should add a warning if you find yourself removing
a BSS that is very young....

Thanks,
Ben


-- 
Ben Greear <greearb at candelatech.com>
Candela Technologies Inc  http://www.candelatech.com