> or the Internet. (Just think: the first AP with a standards-compliant
> IAPP could run NetBSD, provided 802.11f ever emerges from committee. =)

First of all, I know almost nothing about IAPP or 802.11f.
Does IAPP affect the basic management frame in 802.11?  For example,
if an AP want to respond to Association-Request, does it need to interact
someone via IAPP to make a decition if it is OK?

I thought IAPP runs just after normal association completed, as 802.11i.
If so, basic AP functions can be independent for such daemon.

As for 802.11i, I'm thinking to split bridge functions from current AP
code, and merge it into if_bridge.  It should be possible to implement
generic 802.1x architecture not only for 802.11i, but also normal
wired ethernet.

After that, the only required APIs for AP code are configuring per-client
key, and maybe notification of IV exhaustion.  The latter is an
asynchronous event and requires re-keying for, e.g, host-ap daemon.
The event notification cannot be done via ifioctl(), and it is not
suitable for bpf().  So making pseudo charactor device would be
good for the purpose.

Since 802.11i runs only after association completed and uses only DATA
frame, it doesn't affect normal scan-auth-assoc sequence.  Perhaps bpf
can be used for EAPOL, the current code doesn't handle transmitting
special frame other than normal ethernet frame.

We also need some APIs for bridge to control block/unblock client, and
some kernel internal API to configure the cache entry.  It is not
reasonable for AP to enable discovery/learning function.

So I'm not sure we need APIs to affect normal scan-auth-assoc sequence
in HostAP.

Atsushi Onoe