From: Johannes Berg <[email protected]>
In many cases, userspace may need to know which of the
extended capabilities are implemented in the driver or
device, to include them e.g. in beacons, association
request/response or other frames. Add a new nl80211
attribute that holds the extended capabilities bitmap
supported by the driver/device for this.
Signed-off-by: Johannes Berg <[email protected]>
---
include/net/cfg80211.h | 8 ++++++++
include/uapi/linux/nl80211.h | 8 ++++++++
net/wireless/nl80211.c | 9 +++++++++
3 files changed, 25 insertions(+)
diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index bc670b2..d84e7fd 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -2463,6 +2463,11 @@ struct wiphy_wowlan_support {
*
* @max_acl_mac_addrs: Maximum number of MAC addresses that the device
* supports for ACL.
+ *
+ * @extended_capabilities: extended capabilities supported by the driver,
+ * additional capabilities might be supported by userspace
+ * @extended_capabilities_mask: mask of the valid values
+ * @extended_capabilities_len: length of the extended capabilities
*/
struct wiphy {
/* assign these fields before you register the wiphy */
@@ -2529,6 +2534,9 @@ struct wiphy {
*/
u32 probe_resp_offload;
+ const u8 *extended_capabilities, *extended_capabilities_mask;
+ u8 extended_capabilities_len;
+
/* If multiple wiphys are registered and you're handed e.g.
* a regular netdev with assigned ieee80211_ptr, you won't
* know whether it points to a wiphy your driver has registered
diff --git a/include/uapi/linux/nl80211.h b/include/uapi/linux/nl80211.h
index 1ed7e1c..69d50fe 100644
--- a/include/uapi/linux/nl80211.h
+++ b/include/uapi/linux/nl80211.h
@@ -1342,6 +1342,11 @@ enum nl80211_commands {
* number of MAC addresses that a device can support for MAC
* ACL.
*
+ * @NL80211_ATTR_EXT_CAPA: Extended capabilities that the kernel driver
+ * has and handles. The format is the same as the IE contents.
+ * @NL80211_ATTR_EXT_CAPA_MASK: Extended capabilities that the kernel driver
+ * has set in the %NL80211_ATTR_EXT_CAPA value, for multibit fields.
+ *
* @NL80211_ATTR_MAX: highest attribute number currently defined
* @__NL80211_ATTR_AFTER_LAST: internal use
*/
@@ -1620,6 +1625,9 @@ enum nl80211_attrs {
NL80211_ATTR_MAC_ACL_MAX,
+ NL80211_ATTR_EXT_CAPA,
+ NL80211_ATTR_EXT_CAPA_MASK,
+
/* add attributes here, update the policy in nl80211.c */
__NL80211_ATTR_AFTER_LAST,
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index b19c822..1908b70 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -1354,6 +1354,15 @@ static int nl80211_send_wiphy(struct sk_buff *msg, u32 portid, u32 seq, int flag
dev->wiphy.max_acl_mac_addrs))
goto nla_put_failure;
+ if (dev->wiphy.extended_capabilities &&
+ (nla_put(msg, NL80211_ATTR_EXT_CAPA,
+ dev->wiphy.extended_capabilities_len,
+ dev->wiphy.extended_capabilities) ||
+ nla_put(msg, NL80211_ATTR_EXT_CAPA_MASK,
+ dev->wiphy.extended_capabilities_len,
+ dev->wiphy.extended_capabilities_mask)))
+ goto nla_put_failure;
+
return genlmsg_end(msg, hdr);
nla_put_failure:
--
1.8.0
From: Johannes Berg <[email protected]>
Use the new extended capabilities advertising to advertise
the fact that operating mode notification is supported.
Signed-off-by: Johannes Berg <[email protected]>
---
include/linux/ieee80211.h | 2 ++
net/mac80211/main.c | 9 +++++++++
2 files changed, 11 insertions(+)
diff --git a/include/linux/ieee80211.h b/include/linux/ieee80211.h
index 4aed928..9164c45 100644
--- a/include/linux/ieee80211.h
+++ b/include/linux/ieee80211.h
@@ -1788,6 +1788,8 @@ enum ieee80211_tdls_actioncode {
#define WLAN_EXT_CAPA5_TDLS_ENABLED BIT(5)
#define WLAN_EXT_CAPA5_TDLS_PROHIBITED BIT(6)
+#define WLAN_EXT_CAPA8_OPMODE_NOTIF BIT(6)
+
/* TDLS specific payload type in the LLC/SNAP header */
#define WLAN_TDLS_SNAP_RFTYPE 0x2
diff --git a/net/mac80211/main.c b/net/mac80211/main.c
index 38b3468..26531a3 100644
--- a/net/mac80211/main.c
+++ b/net/mac80211/main.c
@@ -501,6 +501,11 @@ static const struct ieee80211_ht_cap mac80211_ht_capa_mod_mask = {
},
};
+static const u8 extended_capabilities[] = {
+ 0, 0, 0, 0, 0, 0, 0,
+ WLAN_EXT_CAPA8_OPMODE_NOTIF,
+};
+
struct ieee80211_hw *ieee80211_alloc_hw(size_t priv_data_len,
const struct ieee80211_ops *ops)
{
@@ -557,6 +562,10 @@ struct ieee80211_hw *ieee80211_alloc_hw(size_t priv_data_len,
WIPHY_FLAG_REPORTS_OBSS |
WIPHY_FLAG_OFFCHAN_TX;
+ wiphy->extended_capabilities = extended_capabilities;
+ wiphy->extended_capabilities_mask = extended_capabilities;
+ wiphy->extended_capabilities_len = ARRAY_SIZE(extended_capabilities);
+
if (ops->remain_on_channel)
wiphy->flags |= WIPHY_FLAG_HAS_REMAIN_ON_CHANNEL;
--
1.8.0
On Wed, 2013-02-27 at 13:30 +0100, Piotr Haber wrote:
> seems like this patch pushed wiphy info length over the limit
> for dual band devices.
> So userspace cannot get any info about phy capabilities.
Yeah ... was it this patch? I did revert some others, but I guess it
depends.
> I know there is a patch for nl80211 and iw to allow splitting of this info,
> but it is not in 3.8
> Should we not revert it for stable then?
Yeah we can revert this too, a la the patches already in to remove TCP
wakeup and radar info. What kernel are you testing?
johannes
On 02/12/13 15:01, Johannes Berg wrote:
> From: Johannes Berg <[email protected]>
>
> In many cases, userspace may need to know which of the
> 802.11 extended capabilities ("Extended Capabilities
> element") are implemented in the driver or device, to
> include them e.g. in beacons, assoc request/response
> or other frames. Add a new nl80211 attribute to hold
> the extended capabilities bitmap for this.
>
Hi,
seems like this patch pushed wiphy info length over the limit
for dual band devices.
So userspace cannot get any info about phy capabilities.
I know there is a patch for nl80211 and iw to allow splitting of this info,
but it is not in 3.8
Should we not revert it for stable then?
Kind regards
Piotr
On 02/27/13 13:32, Johannes Berg wrote:
> On Wed, 2013-02-27 at 13:30 +0100, Piotr Haber wrote:
>
>> seems like this patch pushed wiphy info length over the limit
>> for dual band devices.
>> So userspace cannot get any info about phy capabilities.
>
> Yeah ... was it this patch? I did revert some others, but I guess it
> depends.
did not bisect, but that was the last big thing added there
>> I know there is a patch for nl80211 and iw to allow splitting of this info,
>> but it is not in 3.8
>> Should we not revert it for stable then?
>
> Yeah we can revert this too, a la the patches already in to remove TCP
> wakeup and radar info. What kernel are you testing?
>
i have one built from wireless-testing master-2013-02-19