HostAP IAPP code
Mon Oct 4 22:58:52 PDT 2004
On Thu, Sep 30, 2004 at 08:04:54AM +0200, Reto Bucher wrote:
> if i'm right, IAPP of hostAP does only cover the very basic
> functionality of 802.11f.
hostapd had early, limited implementation of IEEE 802.11f draft 3
(mainly, Layer 2 Update and IAPP ADD-notify).
> Are there any ongoing activities to add some functionality to hostAP
> (e.g IAPP caching, ...)? Or are there any plans?
Well.. There has been couple of questions on this topic earlier, but not
very much activity. I went quickly through the IEEE 802.11F-2003 now and
updated hostapd to use assigned UDP port and changed local broadcast to
multicast for IAPP ADD-notify. In addition, I wrote number of to-do
comments in hostapd/iapp.c if someone were interested in doing something
Level 1 support for IAPP (i.e., just static BSSID->IP addr mapping in
each AP and no support for security) would be quite a small change.
Level 2/3 support would require more work for RADIUS operations and
> Or, as a very basic question: is IAPP slowly dying?
IEEE 802.11F-2003 is trial-use recommended practice, not amendment to
IEEE 802.11 standard. It will expire next summer if it is not revised
and I haven't really noticed much activity within IEEE 802.11 working
group to do anything about this. In other words, I'm not too surprised
if it ends up going the way of dodo..
I can see some uses for the current IAPP, mainly the IAPP ADD-notify
(and MOVE-notify/response to some extent) to clear old association data
from APs. However, further use for IEEE 802.11, like context transfer,
is quite open. IEEE 802.11F-2003 itself does not specify what kind of
context would be transferred, it just provides a mechanism for
transferring such data..
I haven't seen concrete plans on what people would like to do with IAPP.
If someone has one, it would be interesting to get some details (e.g.,
what problem is being solved, what context data is transferred, etc.).
Jouni Malinen PGP id EFC895FA
More information about the Hostap