From: Jouni Malinen (jkmaline_at_cc.hut.fi)
Date: 2002-09-08 18:37:12 UTC
On Sun, Sep 08, 2002 at 12:47:46AM -0700, Erik Walthinsen wrote:
> FYI, I'm working on putting all the relevant kernel-interface bits of
> hostapd into library form, with my primary intent being to use SWIG to
> generate Python bindings. Jouni, would you want to merge this into
> mainline eventually, with hostapd.so and hostapd just containing the main
> logic?
Hmm.. Could you give some examples of what that would be used? I'm not sure that I really understood the purpose of this.. I would understand making wrappers for things like hostap_crypt_conf that takes care of configuring kernel driver encryption, but hostapd is quite a bit different. hostapd.so would sound like some part of the hostapd daemon would be moved to a shared library. I'm not very fond of that idea unless there are good reasons for doing it.
> My goal with the Python bindings is to write hostapd in my MetaNet
> framework, so it can be closely integrated with other subsystems. An
> example cool feature would be to correlate associates with ARP, working
> with an anti-spoofing system. Another useful project would be to
> eventually have the depth of authentication backends that NoCat does, and
> be able to use that for hostap.
I'm not familiar with MetaNet framework, so again, I might be missing something here.. I have been planning on a bit different method for interfacing with Host AP kernel driver and hostapd daemon. I would see hostapd as the daemon that takes care of IEEE 802.11 management (and now also IEEE 802.1X and in the future IAPP) and configures the kernel driver with everything it needs to know and in the future also collects accounting statistics from the kernel driver. I would also consider including things like iptables configuration and gratuitous ARP sending to hostapd. From this viewpoint, there would not be much need for other user space programs to communicate directly with the Host AP kernel driver.
hostapd will at some point get some sort of API (e.g., using unix domain sockets) for quering status information and performing dynamic configuration (e.g., get info events about new/leaving stations, get station TX/RX counters, authorize/unauthorize access, etc.). Other user space programs would then use this API to do whatever they want to do with the AP management. This could include things like authentication and authorization (when something else than IEEE 802.1X is used).
> Actually, it would be useful to have a more general library, handling
> *all* the things you might do that are hostap specific. Though without
> having gone too far into hostap yet, it very well may be that hostapd does
> encompass everything that's unique about the hostap driver vs. other wifi
> drivers.
hostapd is supposed to be as generic as possible as far as different wifi drivers are concerned. At the moment, this is not exactly true, since there are some Host AP kernel driver dependent code included (mostly in hostapd.c), but amount of this code is quite small.
It could be useful to design a suitable generic API for the needed operations (configuring station data and individual WEP keys to the kernel driver) or at least move the driver specific code to a separate file. This should make it cleaner to add support for other wlan drivers that would support host-based access point functionality.
-- Jouni Malinen PGP id EFC895FA