Add option to have more than one process listen for beacons per wiphy?
We have been using one hostapd process per virtual AP interface.
With the commit below, this stopped working because the second hostapd would fail to register as a beacon listener since the first was already registered.
commit 5e760230e42cf759bd923457ca2753aacf2e656e
Author: Johannes Berg <[email protected]> Date: Fri Nov 4 11:18:17 2011 +0100
cfg80211: allow registering to beacons
Add the ability to register to received beacon frames to allow implementing OLBC logic in userspace. The registration is per wiphy since there's no point in receiving the same frame multiple times.
To me, this is a regression bug and worth fixing.
I would like to write up some patch that allows more than one hostapd to run per wiphy interface (basically, one per VAP interface).
A simple means would be a fixed-length array of nlpids (with max of maybe 16 or so). Or, could do a variable length array, or list, or some other way to register more than one at a time. If it were up to me, I'd choose a fixed-length array just to keep the code simple.
Any opinions on this?
Thanks,
Ben
Signature · 2 lines
Ben Greear <[email protected]> Candela Technologies Inc http://www.candelatech.com
Quoted 6 lines · Ben Greear
A simple means would be a fixed-length array of nlpids (with max of maybe 16 or so). Or, could do a variable length array, or list, or some other way to register more than one at a time. If it were up to me, I'd choose a fixed-length array just to keep the code simple.
Any opinions on this?
Fixed-length seems like a bad idea, you'll eventually complain about it again :P
A list of small structures like the management frame registrations seems like the best option?
Alternatively, we could have a new multicast group but that'd also require hostapd changes.
johannes