Search Linux Wireless

Re: [PATCH 2/2] cfg80211/nl80211: Enable drivers to implement mac address based ACL

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





On Wednesday 12 December 2012 04:56 PM, Johannes Berg wrote:
On Wed, 2012-12-12 at 10:46 +0530, Vasanthakumar Thiagarajan wrote:

On Wednesday 12 December 2012 01:27 AM, Johannes Berg wrote:
On Fri, 2012-12-07 at 17:16 +0530, Vasanthakumar Thiagarajan wrote:
This patch enables drivers to implement mac address based
access control in AP/P2P GO mode. There is a new flag in
nl80211_ap_sme_features (NL80211_AP_SME_FEATURE_MAC_ACL)
for drivers to advertise this capability. There are two acl
policies, white and black list under which an acl list can
be configured in the driver. Driver has to advertise the
maximum number of mac address entries in acl list through
max_acl_mac_addrs of wiphy.

Driver can enable its ACL either with the initial list passed
through NL80211_CMD_START_AP or a list passed through
NL80211_CMD_SET_MAC_ACL. ACL information passed in these
commands is an array of acl configuration containing acl
policy and list of mac address. With the acl policy as
NL80211_ACL_POLICY_ACCEPT, driver will accept Auth request
from any client matching any one of the mac addresses in the acl list.
When acl policy is NL80211_ACL_POLICY_DENY, driver will reject any
Auth request from the clients having their mac address listed in the
acl list. Driver must make sure to clear it's acl list when doing
stop ap.

It seems easy to imagine a device that supports only a blacklist or
whitelist, not both combined? What's the point of that anyway?

No, the assumption is driver can support both the lists, but a
particular mac address can not be part of both the lists.
List of mac address for both the lists can be sent in
NL80211_CMD_START_AP and NL80211_CMD_SET_MAC_ACL.

Yeah but I don't think that's a valid general assumption, and with the
feature advertising API that you came up with, the driver can't
advertise that it supports both at the same time etc.

Sure, seems like needs to be supported acl policy flags for the
driver to advertise.


Also, in fact, I think there needs to be more justification for why you
need two lists to start with  -- it seems to me that a white- and
blacklist doesn't make sense at all, unless it's not really a white- and
blacklist but one of
  1) a blacklist
  2) a whitelist + a "do not notify" list

Here the white and black list are real white and black list.
The mac address listed under white list are allowed to connect
while the ones available on black are blocked unconditionally
from connection. If a station's mac is part of neither of the lists,
that needs to be notified which is missing now. It is not very clear
to me about how the notification needs to be done, is it through
NL80211_ATTR_CONN_FAILED_REASON in NL80211_CMD_CONN_FAILED or
there needs to be new command/attr?.


So there may be your feature advertising paradigm. Think of other
devices, don't restrict yourself to ath6kl.

You mean there needs to be mechanism for drivers to advertise the
support these various acl policy as mentioned above?.

Vasanth
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Host AP]     [ATH6KL]     [Linux Wireless Personal Area Network]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [Linux Kernel]     [IDE]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite Hiking]     [MIPS Linux]     [ARM Linux]     [Linux RAID]

  Powered by Linux