Add option to have more than one process listen for beacons per wiphy?

Add option to have more than one process listen for beacons per wiphy?

[Ben Greear]

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 <johannes.berg@intel.com>
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.

     Signed-off-by: Johannes Berg <johannes.berg@intel.com>
     Signed-off-by: John W. Linville <linville@tuxdriver.com>


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

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

Re: Add option to have more than one process listen for beacons per wiphy?

[Johannes Berg]

On Mon, 2012-10-22 at 16:48 -0700, Ben Greear wrote:

> 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