hosted dynamically ignore/respond to probe request from stations

[Ben Greear]

On 10/23/2013 07:23 AM, Jouni Malinen wrote:
> On Wed, Oct 23, 2013 at 10:16:30AM -0400, Amit Shah wrote:
>> Hi jouni thank you for your feedback. Is there another means by which I can
>> extend the code base to achieve what I want? The deployment scenario is an
>> auditorium ( high density ). I wanted to stop beaconing so neighbouring
>> nodes would continue to beacon and a client station would select a
>> neighbouring node to connect to. On an aside I don't understand why just
>> manipulating ignore_broadcast_request doesn't achieve my hack. Is there
>> another area that controls the beaconing outside of beacon.c? Your help is
>> greatly appreciated.
> 
> You cannot stop beaconing without breaking almost everything (power save
> and most stations dropping connection due to missed beacon frames). You
> could potentially consider not replying to Probe Request frames from any
> station that is not associated with the specific AP to reduce some
> traffic, but in general, it is quite difficult to improve high density
> cases without changes to the standard (which are being worked on) and
> implementations both in the AP and station side.
> 
> If you are just trying to steer new stations to other APs, you could
> either do some pretty bad hacks (which I would not recommend due to
> interop issues with stations) that various enterprise APs use today or
> start looking at things that will be coming from new standards
> development efforts.

That code-17 patch I posted some time back should help with this.
It will actively deny associations after the AP's limit has been
reached, and clients *should* scan for others.

Thanks,
Ben

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