hostap + mac filtering

[Sam Leffler]

Jouni Malinen wrote:
> On Tue, Sep 27, 2005 at 10:37:53PM -0400, Bryan Kadzban wrote:
> 
> 
>>With our old Orinoco APs, when we configured a MAC ACL, any MAC address
>>that wasn't allowed according to that list wasn't even allowed to
>>associate.  Sounds like those APs did that in the driver, too.  (They
>>used Atheros radios, but I don't know what OS.)
> 
> 
> This does not necessarily mean it was done in the driver. As an example,
> Host AP driver supports MAC ACL both with and without hostapd. With
> hostapd, it is up to hostapd to do filtering and without hostapd, driver
> will do this.
> 
> 
>>The aforementioned Orinoco APs also had a "MAC access control by RADIUS"
>>option (the Ciscos that we use now have the same thing), which works
>>similarly -- the AP allows anyone to associate, but if the RADIUS server
>>sends an Access-Reject, then that client can't pass traffic through the
>>AP.  Sounds vaguely similar to what you're considering here.
>>
>>I wonder if a "MAC access control by RADIUS" feature would be helpful in
>>hostapd.
> 
> 
> It is already supported in hostapd with Prism2. Though, hostapd is doing
> this at the same time as the static MAC ACLs, i.e., before association.
> In case of madwifi, this could be done by having a way for hostapd to
> register a callback for madwifi to ask whether a STA is allowed to
> authenticate.

Set the net80211 layer into "external authenticator mode" (as used for 
wpa, etc); then hostapd can decide whether or not to authorize traffic 
after querying the radius server.  Doesn't give control before associate 
but perhaps it's sufficient.

> 
> 
>>   The Orinoco APs were configurable; the username was the MAC
>>address in one of 4 formats (xx.xx.xx..., xx-xx-xx..., xxxxxx-xxxxxx, or
>>one other one that I can't remember anymore), and the password was the
>>RADIUS shared secret.  The Cisco APs send a username of xxxxxxxxxx, and
>>the password is the same as the username.
> 
> 
>>If someone plans on doing this, they might as well come up with as many
>>username/password format options as possible, and make it configurable.
> 
> 
> This is very much configurable.. In hostapd source code.. ;-) Anyway, I
> don't see much point in spending much more time with this kind of
> feature.

I agree this discussion has been exhausted but just to clarify things; 
hostapd is integrated with the net80211 layer in madwifi _purely_ to do 
authentication (in fact when I first did the integration I renamed it so 
folks wouldn't look for things like mac acls :)).  Unfortunately there's 
no way for a driver to identify that hostapd features are not supported 
so hostapd can notify users.

	Sam