bss_max_count needed in real-world scenario

[Jouni Malinen]

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?

> 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.

-- 
Jouni Malinen                                            PGP id EFC895FA