From: Jouni Malinen (jkm_at_ssh.com)
Date: 2002-02-12 13:41:40 UTC
On Mon, Feb 11, 2002 at 10:19:57PM +0100, Benedikt 'Hunz' Heinz wrote:
> I hacked a MAC-access list in the driver - there are 3 policies -
> open,allow,deny
> open - which is default - ignores the list - everyone can auth at the AP
> allow - only MACs in the list may auth at the AP
> deny - everyone but the MACs from the list may auth at the AP
This is something I would like to integrate in the driver at some point. However, this would end up being more or less fully in the user space.
> also ist is possible to kick associated STAs from the AP - but this
> isn't tested very well and no mgmt-msg are yet sent to the STA before
> removing the STA
Well.. Current version of the driver has a similar limitation with inactivity expiration. It should also notify the station just in case it is still present.
> i dunno wether there's a better answer on the auth if the MAC ist
> rejected - i currently send a WLAN_STATUS_UNSPECIFIED_FAILURE
Not really.. I haven't checked what code other APs use, but at least I did not find any better alternative from IEEE 802.11.
> i use a chardev to control the list via ioctls (devfs not yet
> supported):
> crw-r--r-- 1 root root 42, 0 Feb 11 17:26 /dev/ap0
> (mknod /dev/ap0 c 42 0)
> and a procdev (/proc/net/prism2/wlanX/ap_control) to view the policy and
> MAC-list
> there's a tool in the package called ap_ctrl to control the accesslist
devfs and automatically allocated major/minor numbers would be nice..
> maybe it's possible to add it in the original HostAP package with some
> modifications and cleanups (yes i DO know it's an absolute dirty hack!)
Yes, I'm going to look into this after I get other queued items done.
> another suggestion: the AP-driver logs quite a lot via syslog - maybe
> it's better to build a event-device (/dev/ap0?) which transfers the
> events to userspace to a daemon which handles the events? (seems to be
> better than polling the files in /proc in my eyes)
Yes, this would certainly be better. I have been planning to add a mechanism for communication with a user space daemon. This would include handling of authentication and association frames (i.e., this MAC based filtering could be done fully in user space after this).
Character device with dynamically allocated major/minor numbers per WLAN interface might be good solution for this. The driver could register these /dev entries with devfs (e.g., /proc/hostap/ap###). This chrdev could then be used for passing management frames between the driver and user space daemon. All the event logging etc. could also be sent using the same chrdev.
-- Jouni Malinen SSH Communications Security Corp jouni.malinen_at_ssh.com