Support passing SSID and probe-response template to drivers.
This data can be used to offload the beacon -> probe-req -> probe-resp
process to HW.
v1->v2: Add probe response template configuration
Arik Nemtsov (6):
nl80211: allow passing SSID in nl80211_set_bss
nl80211: Pass probe response data to drivers
mac80211: add SSID for AP mode with change notification
mac80211: Save probe response data for BSS
wl12xx: AP mode - support hidden SSID
wl12xx: configure probe-resp template according to notification
drivers/net/wireless/wl12xx/cmd.c | 23 +++++++++-----------
drivers/net/wireless/wl12xx/main.c | 32 +++++++++++++++++++++++++++-
include/linux/nl80211.h | 9 ++++++++
include/net/cfg80211.h | 8 +++++++
include/net/mac80211.h | 21 ++++++++++++++++++
net/mac80211/cfg.c | 40 ++++++++++++++++++++++++++++++++++++
net/mac80211/ieee80211_i.h | 1 +
net/mac80211/iface.c | 5 +++-
net/mac80211/tx.c | 31 +++++++++++++++++++++++++++
net/mac80211/util.c | 8 ++++++-
net/wireless/nl80211.c | 40 ++++++++++++++++++++++++++++++++++++
11 files changed, 202 insertions(+), 16 deletions(-)
On Wed, Jan 26, 2011 at 08:24:32AM +0200, Arik Nemtsov wrote:
> Just to clear up - I don't want to disable p2p or wps support in
> hostapd if probe-resp offloading is configured. The low level
> driver/fw could realistically differentiate between regular and
> non-support probe requests, and only handle the former.
> The kind of capability flag you asked won't work with such a low lever
> driver/fw combo. Is muti-ssid support currently implemented?
You may not want to disable something, but I do want
hostapd/wpa_supplicant to be able disable P2P or other features if it is
not clear the the driver is unable to support them correctly. Knowing
whether the driver is planning on using hostapd for processing Probe
Request frames is a key for this and as such, I cannot support use of
this functionality in hostapd/wpa_supplicant before that driver
capability information is exposed to user space.
How would the firmware be aware of new protocols that pop up every now
and then? There does not seem to be any other way of doing this reliably
apart from being able to advertise support for protocol specific needs
like adding a P2P-Probe-Request-offload capability and
P2P-Probe-Request-will-be-passed-up-but-everything-else-offloaded
capability when support for P2P is added. Similar flags would then be
needed for whatever new protocol comes up with silly Probe Request
processing requirements.
Parts of multi-SSID support are in hostapd, but I do not think it is
enabled at the moment.
> How about a different solution - I'll just disable p2p IEs for the
> probe-resp template for now. Let's assume the FW behaves correctly in
> this case and passes up the probe-requests. The code for generating
> the WPS IE for the probe-resp seems to not depend on the probe-req. Is
> the feature of WPS 2.0 you mentioned currently implemented? If so this
> can be disabled as well.
Disable where? And how would hostapd/wpa_supplicant know that something
is disabled? We cannot design a new driver interface that depends on an
assumed hack in a firmware of one device. This needs to be usable by
other drivers, too, and unless such assumptions are clearly documented
(and not randomly changing) it will be difficult to see consistent
behavior between different drivers and user space applications.
--
Jouni Malinen PGP id EFC895FA
On Mon, Jan 24, 2011 at 13:41, Johannes Berg <[email protected]> wrote:
> On Sun, 2011-01-23 at 23:02 +0200, Arik Nemtsov wrote:
>> Support passing SSID and probe-response template to drivers.
>> This data can be used to offload the beacon -> probe-req -> probe-resp
>> process to HW.
>
> I still think you should add a wiphy flag and advertise it in nl80211 to
> advertise and request this behaviour. That will allow hostapd (and
> mac80211 in IBSS mode) to not reply to probe requests when they aren't
> filtered out by the device, and will allow hostapd/wpa_s to also
> restrict its operation to non-P2P etc. as Jouni pointed out. For P2P
> then that will have to be extended more I guess, and the firmware
> functionality be improved -- or even disabled.
>
Well a wiphy flag won't do here. Probe requests may be filtered in
some modes (AP-mode) but needed in others (p2p?).
I think flexibility is a nice added bonus here. A FW can decide to
handle most standard probe-requests and simply not pass them up.
Others ("complicated" ones) it can pass up to hostapd and expect it to reply.
The current patches leave this policy in the hands of the driver/fw.
Regards,
Arik
wl12xx require knowledge of the real SSID when operating as AP
with SSID hidden in beacon data. Allow passing the real SSID from
usermode apart from beacon data.
Signed-off-by: Arik Nemtsov <[email protected]>
---
include/net/cfg80211.h | 5 +++++
net/wireless/nl80211.c | 8 ++++++++
2 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index 1322695..03b1b0c 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -607,6 +607,9 @@ struct mpath_info {
* @ap_isolate: do not forward packets between connected stations
* @ht_opmode: HT Operation mode
* (u16 = opmode, -1 = do not change)
+ * @ssid_len: length of ssid string
+ * (>0 = ssid_len, -1 = do not change)
+ * @ssid: SSID string (for AP mode). NULL termination not required.
*/
struct bss_parameters {
int use_cts_prot;
@@ -616,6 +619,8 @@ struct bss_parameters {
u8 basic_rates_len;
int ap_isolate;
int ht_opmode;
+ int ssid_len;
+ u8 *ssid;
};
/*
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index 9b62710..ce5453d 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -2576,6 +2576,7 @@ static int nl80211_set_bss(struct sk_buff *skb, struct genl_info *info)
params.use_short_slot_time = -1;
params.ap_isolate = -1;
params.ht_opmode = -1;
+ params.ssid_len = -1;
if (info->attrs[NL80211_ATTR_BSS_CTS_PROT])
params.use_cts_prot =
@@ -2597,6 +2598,13 @@ static int nl80211_set_bss(struct sk_buff *skb, struct genl_info *info)
if (info->attrs[NL80211_ATTR_BSS_HT_OPMODE])
params.ht_opmode =
nla_get_u16(info->attrs[NL80211_ATTR_BSS_HT_OPMODE]);
+ if (info->attrs[NL80211_ATTR_SSID]) {
+ params.ssid = nla_data(info->attrs[NL80211_ATTR_SSID]);
+ params.ssid_len = nla_len(info->attrs[NL80211_ATTR_SSID]);
+ if (params.ssid_len == 0 ||
+ params.ssid_len > IEEE80211_MAX_SSID_LEN)
+ return -EINVAL;
+ }
if (!rdev->ops->change_bss)
return -EOPNOTSUPP;
--
1.7.1
On Tue, Jan 25, 2011 at 12:10, Johannes Berg <[email protected]> wrote:
> On Mon, 2011-01-24 at 23:21 +0200, Arik Nemtsov wrote:
>
>> Well a wiphy flag won't do here. Probe requests may be filtered in
>> some modes (AP-mode) but needed in others (p2p?).
>> I think flexibility is a nice added bonus here. A FW can decide to
>> handle most standard probe-requests and simply not pass them up.
>> Others ("complicated" ones) it can pass up to hostapd and expect it to reply.
>>
>> The current patches leave this policy in the hands of the driver/fw.
>
> That is _very_ dangerous. If the user has older firmware that doesn't
> know about WSC2, how would the user know not to configure WSC2 in
> hostapd? That needs to be known to hostapd so it can verify this
> situation. For P2P, we already know whether or not P2P is supported, but
> that's rather vague in case there will ever be a revision of the P2P
> spec with say different IEs.
Well basically the FW should white-list probe-requests it knows about
and pass up all the rest.
>
> Additionally, a "regular AP" (not P2P, not WSC) would still want to
> reply to probe requests from WSC/P2P devices with the normal template.
>
> IMHO it would be smarter to rework the firmware to only reply to probe
> requests if the probe response is configured. Then, if WSC, P2P, or
> similar technologies are in use on the interface, hostapd can simply
> decide to not configure the probe response and have host-based
> processing. Would that be a change you could still make?
With the current set of patches the decision is left at the hands of
the driver/fw. Hostapd currently doesn't have a way of toggling
probe-resp offloading in the low level driver.
This kind of plumbing is not needed in case the FW handles what it can
and passes up unknown probe-requests.
Arik
[let me take both your emails at once]
> > That is _very_ dangerous. If the user has older firmware that doesn't
> > know about WSC2, how would the user know not to configure WSC2 in
> > hostapd? That needs to be known to hostapd so it can verify this
> > situation. For P2P, we already know whether or not P2P is supported, but
> > that's rather vague in case there will ever be a revision of the P2P
> > spec with say different IEs.
>
> Well basically the FW should white-list probe-requests it knows about
> and pass up all the rest.
Indeed. But we need to know what things the firmware knows about, so we
can disable additional functionality automatically.
> > IMHO it would be smarter to rework the firmware to only reply to probe
> > requests if the probe response is configured. Then, if WSC, P2P, or
> > similar technologies are in use on the interface, hostapd can simply
> > decide to not configure the probe response and have host-based
> > processing. Would that be a change you could still make?
>
> With the current set of patches the decision is left at the hands of
> the driver/fw. Hostapd currently doesn't have a way of toggling
> probe-resp offloading in the low level driver.
> This kind of plumbing is not needed in case the FW handles what it can
> and passes up unknown probe-requests.
Well, it could trivially have this functionality by simply not setting
the SSID/probe response frame -- older hostapd would "automatically" not
use this feature, and you'd even have a good upgrade path -- the feature
is only used for new hostapd, and then only when hostapd knows that it
is possible to use the feature.
> Its also conceivable that an old driver/fw won't work when some
> protocol is changed/updated, even if hostapd supports it.
> I'm not sure the probe-resp will be the culprit here..
Indeed. But in such cases, we've dealt with it. But with a simple update
like for example WSC 3.0 (which I don't think is being planned yet, but
may eventually be written) your approach would certainly require a
firmware update. I think that's a bit undesirable, but I'm not saying
that you _need_ to change the firmware. I'm merely recommending that if
the firmware doesn't know the SSID, it will pass up all probe requests.
It has to have the "pass up" functionality already for P2P/WSC2, so that
could trivially be extended to pass up when the driver sets a certain
bit to request it always.
It's been pointed out to me that maybe I'm not always communicating
things effectively -- so let me try to write a summary of the entire
thing again:
The way you're implementing this feature right now _relies_ on the
firmware to do the right thing for all protocols. However,
hostapd/wpa_supplicant have no way of knowing what protocols the
firmware knows about, and they will almost certainly be extended for
more protocols in the future. This I don't want to see -- I want you to
advertise in nl80211 what protocols (including their versions) the
firmware knows about, so that a future hostapd can automatically disable
new protocols that the firmware doesn't know about.
I'm also _recommending_ that you change the firmware implementation to
guard against that and be more backward compatible: allow the driver to
set a bit meaning "pass up all probe requests". Yes, that will destroy
host power savings obtained by this feature if enabled, but will allow
hostapd/wpa_s to implement new features and one could then actually at
least test, if not use, them with the older device. You could also get
rid of the beacon parsing code etc. and simply require that a modern
hostapd that implements the offload be used for maximum power saving.
johannes
Allow usermode to pass probe-response data. This data can be used as a
template probe-response offloading.
Signed-off-by: Arik Nemtsov <[email protected]>
---
include/linux/nl80211.h | 9 +++++++++
include/net/cfg80211.h | 3 +++
net/wireless/nl80211.c | 32 ++++++++++++++++++++++++++++++++
3 files changed, 44 insertions(+), 0 deletions(-)
diff --git a/include/linux/nl80211.h b/include/linux/nl80211.h
index 821ffb9..ba19c4b 100644
--- a/include/linux/nl80211.h
+++ b/include/linux/nl80211.h
@@ -410,6 +410,9 @@
* notification. This event is used to indicate that an unprotected
* disassociation frame was dropped when MFP is in use.
*
+ * @NL80211_CMD_SET_PROBE_RESP: Set a Probe Response template to an access
+ * point interface
+ *
* @NL80211_CMD_MAX: highest used command number
* @__NL80211_CMD_AFTER_LAST: internal use
*/
@@ -522,6 +525,8 @@ enum nl80211_commands {
NL80211_CMD_UNPROT_DEAUTHENTICATE,
NL80211_CMD_UNPROT_DISASSOCIATE,
+ NL80211_CMD_SET_PROBE_RESP,
+
/* add new commands above here */
/* used to define NL80211_CMD_MAX below */
@@ -887,6 +892,8 @@ enum nl80211_commands {
* @NL80211_ATTR_MESH_CONFIG: Mesh configuration parameters, a nested attribute
* containing attributes from &enum nl80211_meshconf_params.
*
+ * @NL80211_ATTR_PROBE_RESP: Probe Response template data
+ *
* @NL80211_ATTR_MAX: highest attribute number currently defined
* @__NL80211_ATTR_AFTER_LAST: internal use
*/
@@ -1074,6 +1081,8 @@ enum nl80211_attrs {
NL80211_ATTR_WIPHY_ANTENNA_AVAIL_TX,
NL80211_ATTR_WIPHY_ANTENNA_AVAIL_RX,
+ NL80211_ATTR_PROBE_RESP,
+
/* add attributes here, update the policy in nl80211.c */
__NL80211_ATTR_AFTER_LAST,
diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index 03b1b0c..8b3f427 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -1366,6 +1366,9 @@ struct cfg80211_ops {
int (*set_antenna)(struct wiphy *wiphy, u32 tx_ant, u32 rx_ant);
int (*get_antenna)(struct wiphy *wiphy, u32 *tx_ant, u32 *rx_ant);
+
+ int (*set_probe_resp)(struct wiphy *wiphy, struct net_device *dev,
+ u8 *resp, size_t resp_len);
};
/*
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index ce5453d..50151a2 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -172,6 +172,8 @@ static const struct nla_policy nl80211_policy[NL80211_ATTR_MAX+1] = {
[NL80211_ATTR_MCAST_RATE] = { .type = NLA_U32 },
[NL80211_ATTR_OFFCHANNEL_TX_OK] = { .type = NLA_FLAG },
[NL80211_ATTR_KEY_DEFAULT_TYPES] = { .type = NLA_NESTED },
+ [NL80211_ATTR_PROBE_RESP] = { .type = NLA_BINARY,
+ .len = IEEE80211_MAX_DATA_LEN },
};
/* policy for the key attributes */
@@ -1917,6 +1919,28 @@ static int nl80211_del_beacon(struct sk_buff *skb, struct genl_info *info)
return rdev->ops->del_beacon(&rdev->wiphy, dev);
}
+static int nl80211_set_probe_resp(struct sk_buff *skb, struct genl_info *info)
+{
+ struct cfg80211_registered_device *rdev = info->user_ptr[0];
+ struct net_device *dev = info->user_ptr[1];
+ u8 *resp;
+ size_t resp_len;
+
+ if (!rdev->ops->set_probe_resp)
+ return -EOPNOTSUPP;
+
+ if (dev->ieee80211_ptr->iftype != NL80211_IFTYPE_AP)
+ return -EOPNOTSUPP;
+
+ if (!info->attrs[NL80211_ATTR_PROBE_RESP])
+ return -EINVAL;
+
+ resp = nla_data(info->attrs[NL80211_ATTR_PROBE_RESP]);
+ resp_len = nla_len(info->attrs[NL80211_ATTR_PROBE_RESP]);
+
+ return rdev->ops->set_probe_resp(&rdev->wiphy, dev, resp, resp_len);
+}
+
static const struct nla_policy sta_flags_policy[NL80211_STA_FLAG_MAX + 1] = {
[NL80211_STA_FLAG_AUTHORIZED] = { .type = NLA_FLAG },
[NL80211_STA_FLAG_SHORT_PREAMBLE] = { .type = NLA_FLAG },
@@ -5266,6 +5290,14 @@ static struct genl_ops nl80211_ops[] = {
.internal_flags = NL80211_FLAG_NEED_NETDEV_UP |
NL80211_FLAG_NEED_RTNL,
},
+ {
+ .cmd = NL80211_CMD_SET_PROBE_RESP,
+ .policy = nl80211_policy,
+ .flags = GENL_ADMIN_PERM,
+ .doit = nl80211_set_probe_resp,
+ .internal_flags = NL80211_FLAG_NEED_NETDEV |
+ NL80211_FLAG_NEED_RTNL,
+ },
};
static struct genl_multicast_group nl80211_mlme_mcgrp = {
--
1.7.1
On Wed, 2011-01-26 at 23:51 +0200, Arik Nemtsov wrote:
> On Wed, Jan 26, 2011 at 10:32, Johannes Berg <[email protected]> wrote:
> > On Wed, 2011-01-26 at 08:00 +0200, Arik Nemtsov wrote:
> >
> >> >> > Why use a separate command for this, and not do it like the SSID? I also
> >> >>
> >> >> Its only relevant to AP-mode (at least for now) so bss_conf didn't
> >> >> seem appropriate.
> >> >> Also since its a dynamically allocated buffer it should be protected by RCU.
> >> >
> >> > But all that is unrelated to the nl80211 API, no? Also the SSID already
> >> > uses bss_conf too, and it's AP mode too...
> >>
> >> Do you have a preferred alternative?
> >
> > What's wrong with putting it in the same place as the SSID?
>
> Just put it as a pointer inside ieee80211_bss_conf? (It will still
> have to be RCU managed and all).
> About nl80211 API - I tried making it as similar as possible to the
> way the beacon works, but I guess I can pass it with bss_parameters as
> well.
Wait, no, I don't get it -- what does the nl80211 API have to do with
how mac80211 manages it? I think for the nl80211 API the new command
doesn't make a whole lot of sense. What happens in mac80211 I don't
think matters much.
johannes
When operating in AP-mode, replace probe-response template when a
notification is recieved from mac80211. We preserve the "legacy" way of
configuring a probe-response according to beacon for IBSS mode and for
versions of hostapd that do not support this feature.
Signed-off-by: Arik Nemtsov <[email protected]>
---
drivers/net/wireless/wl12xx/main.c | 32 +++++++++++++++++++++++++++++++-
1 files changed, 31 insertions(+), 1 deletions(-)
diff --git a/drivers/net/wireless/wl12xx/main.c b/drivers/net/wireless/wl12xx/main.c
index 9076555..49d6160 100644
--- a/drivers/net/wireless/wl12xx/main.c
+++ b/drivers/net/wireless/wl12xx/main.c
@@ -2041,6 +2041,25 @@ static int wl1271_ssid_set(struct wl1271 *wl, struct sk_buff *skb,
return -ENOENT;
}
+static int wl1271_ap_set_probe_resp_tmpl(struct wl1271 *wl, u32 rates)
+{
+ struct sk_buff *skb;
+ int ret;
+
+ skb = ieee80211_proberesp_get(wl->hw, wl->vif);
+ if (!skb)
+ return -EINVAL;
+
+ ret = wl1271_cmd_template_set(wl,
+ CMD_TEMPL_AP_PROBE_RESPONSE,
+ skb->data,
+ skb->len, 0,
+ rates);
+
+ dev_kfree_skb(skb);
+ return ret;
+}
+
static int wl1271_bss_erp_info_changed(struct wl1271 *wl,
struct ieee80211_bss_conf *bss_conf,
u32 changed)
@@ -2102,8 +2121,10 @@ static int wl1271_bss_beacon_info_changed(struct wl1271 *wl,
struct sk_buff *beacon = ieee80211_beacon_get(wl->hw, vif);
u16 tmpl_id;
- if (!beacon)
+ if (!beacon) {
+ ret = -EINVAL;
goto out;
+ }
wl1271_debug(DEBUG_MASTER, "beacon updated");
@@ -2139,7 +2160,16 @@ static int wl1271_bss_beacon_info_changed(struct wl1271 *wl,
goto out;
}
+ if ((changed & BSS_CHANGED_AP_PROBE_RESP) && is_ap) {
+ ret = wl1271_ap_set_probe_resp_tmpl(wl,
+ wl1271_tx_min_rate_get(wl));
+ if (ret < 0)
+ goto out;
+ }
+
out:
+ if (ret != 0)
+ wl1271_error("beacon info change failed: %d", ret);
return ret;
}
--
1.7.1
On Mon, Jan 24, 2011 at 13:35, Johannes Berg <[email protected]> wrote:
> On Sun, 2011-01-23 at 23:02 +0200, Arik Nemtsov wrote:
>> Allow usermode to pass probe-response data. This data can be used as a
>> template probe-response offloading.
>
> Why use a separate command for this, and not do it like the SSID? I also
Its only relevant to AP-mode (at least for now) so bss_conf didn't
seem appropriate.
Also since its a dynamically allocated buffer it should be protected by RCU.
> was under the impression you wanted both (which is somewhat redundant
> since you can parse the SSID out of the probe response), so shouldn't
> they both be required (or none, for compatibility)?
The FW requires both the real SSID and a probe-response template.
Passing the SSID separately looked cleaner.
About compatibility - good point there. Currently the probe response
template is set according to the beacon for compatibility. As for SSID
- with the current wl12xx we'll set an empty SSID when a
non-supporting hostapd is encountered. I'll fix that (in a v3). Other
than that, we should be able to operate with either one configured.
>
> Also, should cfg80211 pretend it knows the SSID/probe response when
> userspace didn't set it (from the beacon) so that mac80211 or the
> low-level drivers don't need to worry?
Well in the current patches sent to hostapd the probe response is
always set with the beacon, so this shouldn't happen in AP mode.
Its not supported in these patches for other modes..
Regards,
Arik
Hey Jouni, Johannes,
After discussing this with the wl12xx FW guys, it seems that:
- WPS2 and P2P special cases are currently not handled in FW - the
default template is always returned for probe requests
- The AP currently always responds to a probe request
- The AP currently never passes up probe requests
In light of this new info, this might be a possible solution:
- Implement a capability flag for
ap-supports-offloading-of-basic-probe-reqs. With "basic" I mean WPS1/2
and P2P IEs are not included.
- Hostapd will configure a probe-resp template only when it supports
probe-resp offloading (currently when WPS and P2P are off) and the
driver supports it (using the capability flag).
- Support a "pass and and don't reply to probe requests" mode in FW
(this will take some time to implement).
For now the wl12xx driver must operate in a "compatibility" mode,
since the FW doesn't support passing-up probe requests. When the
probe-resp template is not available we will use the beacon template,
as currently used now. There are currently no plans for intelligent
filtering of probe requests in FW - its all or nothing.
Should hostapd reply to probe requests when offloading is configured?
This is a moot point for wl12xx since probe-requests are not passed
up. Do you have a preference here?
I'd appreciate your comments on this.
Arik
On Tue, Jan 25, 2011 at 12:12, Johannes Berg <[email protected]> wrote:
> On Mon, 2011-01-24 at 22:47 +0200, Arik Nemtsov wrote:
>> On Mon, Jan 24, 2011 at 13:35, Johannes Berg <[email protected]> wrote:
>> > On Sun, 2011-01-23 at 23:02 +0200, Arik Nemtsov wrote:
>> >> Allow usermode to pass probe-response data. This data can be used as a
>> >> template probe-response offloading.
>> >
>> > Why use a separate command for this, and not do it like the SSID? I also
>>
>> Its only relevant to AP-mode (at least for now) so bss_conf didn't
>> seem appropriate.
>> Also since its a dynamically allocated buffer it should be protected by RCU.
>
> But all that is unrelated to the nl80211 API, no? Also the SSID already
> uses bss_conf too, and it's AP mode too...
Do you have a preferred alternative?
>
>> About compatibility - good point there. Currently the probe response
>> template is set according to the beacon for compatibility. As for SSID
>> - with the current wl12xx we'll set an empty SSID when a
>> non-supporting hostapd is encountered. I'll fix that (in a v3). Other
>> than that, we should be able to operate with either one configured.
>
> Does that mean if you set an empty SSID it won't reply but pass them up?
> Then you could implement the behaviour I just asked for ...
Well no. The FW never passes up beacons. You've helped uncover a bug
where a non-supporting hostapd doesn't set the SSID and consequently
we'll have an empty SSID configured to FW.
In this case we should fallback to use the SSID extracted from the beacon.
Arik
Allow setting a probe response template for an interface operating in
AP mode. Low level drivers are notified about changes in the probe
response template and are able to retrieve a copy of the current probe
response. This data can, for example, be uploaded to hardware as a
template.
Signed-off-by: Arik Nemtsov <[email protected]>
---
include/net/mac80211.h | 15 +++++++++++++++
net/mac80211/cfg.c | 33 +++++++++++++++++++++++++++++++++
net/mac80211/ieee80211_i.h | 1 +
net/mac80211/iface.c | 5 ++++-
net/mac80211/tx.c | 31 +++++++++++++++++++++++++++++++
net/mac80211/util.c | 3 ++-
6 files changed, 86 insertions(+), 2 deletions(-)
diff --git a/include/net/mac80211.h b/include/net/mac80211.h
index ff3bad1..55c48a1 100644
--- a/include/net/mac80211.h
+++ b/include/net/mac80211.h
@@ -165,6 +165,7 @@ struct ieee80211_low_level_stats {
* that it is only ever disabled for station mode.
* @BSS_CHANGED_IDLE: Idle changed for this BSS/interface.
* @BSS_CHANGED_SSID: SSID changed for this BSS (AP mode)
+ * @BSS_CHANGED_AP_PROBE_RESP: Probe Response changed for this BSS (AP mode)
*/
enum ieee80211_bss_change {
BSS_CHANGED_ASSOC = 1<<0,
@@ -183,6 +184,7 @@ enum ieee80211_bss_change {
BSS_CHANGED_QOS = 1<<13,
BSS_CHANGED_IDLE = 1<<14,
BSS_CHANGED_SSID = 1<<15,
+ BSS_CHANGED_AP_PROBE_RESP = 1<<16,
/* when adding here, make sure to change ieee80211_reconfig */
};
@@ -2220,6 +2222,19 @@ static inline struct sk_buff *ieee80211_beacon_get(struct ieee80211_hw *hw,
}
/**
+ * ieee80211_proberesp_get - retrieve a Probe Response template
+ * @hw: pointer obtained from ieee80211_alloc_hw().
+ * @vif: &struct ieee80211_vif pointer from the add_interface callback.
+ *
+ * Creates a Probe Response template which can, for example, be uploaded to
+ * hardware. The destination address should be set by the caller.
+ *
+ * Can only be called in AP mode.
+ */
+struct sk_buff *ieee80211_proberesp_get(struct ieee80211_hw *hw,
+ struct ieee80211_vif *vif);
+
+/**
* ieee80211_pspoll_get - retrieve a PS Poll template
* @hw: pointer obtained from ieee80211_alloc_hw().
* @vif: &struct ieee80211_vif pointer from the add_interface callback.
diff --git a/net/mac80211/cfg.c b/net/mac80211/cfg.c
index a2a75e9..834de52 100644
--- a/net/mac80211/cfg.c
+++ b/net/mac80211/cfg.c
@@ -1944,6 +1944,38 @@ static int ieee80211_get_antenna(struct wiphy *wiphy, u32 *tx_ant, u32 *rx_ant)
return drv_get_antenna(local, tx_ant, rx_ant);
}
+static int ieee80211_set_probe_resp(struct wiphy *wiphy,
+ struct net_device *dev, u8 *resp,
+ size_t resp_len)
+{
+ struct ieee80211_sub_if_data *sdata;
+ struct sk_buff *new, *old;
+
+ sdata = IEEE80211_DEV_TO_SUB_IF(dev);
+ old = sdata->u.ap.probe_resp;
+
+ if (!resp || !resp_len)
+ return -EINVAL;
+
+ new = dev_alloc_skb(resp_len);
+ if (!new) {
+ printk(KERN_DEBUG "%s: failed to allocate buffer for probe "
+ "response template\n", sdata->name);
+ return -ENOMEM;
+ }
+
+ memcpy(skb_put(new, resp_len), resp, resp_len);
+
+ rcu_assign_pointer(sdata->u.ap.probe_resp, new);
+ synchronize_rcu();
+
+ if (old)
+ dev_kfree_skb(old);
+
+ ieee80211_bss_info_change_notify(sdata, BSS_CHANGED_AP_PROBE_RESP);
+ return 0;
+}
+
struct cfg80211_ops mac80211_config_ops = {
.add_virtual_intf = ieee80211_add_iface,
.del_virtual_intf = ieee80211_del_iface,
@@ -2001,4 +2033,5 @@ struct cfg80211_ops mac80211_config_ops = {
.mgmt_frame_register = ieee80211_mgmt_frame_register,
.set_antenna = ieee80211_set_antenna,
.get_antenna = ieee80211_get_antenna,
+ .set_probe_resp = ieee80211_set_probe_resp,
};
diff --git a/net/mac80211/ieee80211_i.h b/net/mac80211/ieee80211_i.h
index c47d7c0..4513cc5 100644
--- a/net/mac80211/ieee80211_i.h
+++ b/net/mac80211/ieee80211_i.h
@@ -215,6 +215,7 @@ struct beacon_data {
struct ieee80211_if_ap {
struct beacon_data *beacon;
+ struct sk_buff *probe_resp;
struct list_head vlans;
diff --git a/net/mac80211/iface.c b/net/mac80211/iface.c
index 8acba45..7795778 100644
--- a/net/mac80211/iface.c
+++ b/net/mac80211/iface.c
@@ -449,15 +449,18 @@ static void ieee80211_do_stop(struct ieee80211_sub_if_data *sdata,
if (sdata->vif.type == NL80211_IFTYPE_AP) {
struct ieee80211_sub_if_data *vlan, *tmpsdata;
struct beacon_data *old_beacon = sdata->u.ap.beacon;
+ struct sk_buff *old_probe_resp = sdata->u.ap.probe_resp;
/* sdata_running will return false, so this will disable */
ieee80211_bss_info_change_notify(sdata,
BSS_CHANGED_BEACON_ENABLED);
- /* remove beacon */
+ /* remove beacon and probe response */
rcu_assign_pointer(sdata->u.ap.beacon, NULL);
+ rcu_assign_pointer(sdata->u.ap.probe_resp, NULL);
synchronize_rcu();
kfree(old_beacon);
+ kfree(old_probe_resp);
/* free all potentially still buffered bcast frames */
while ((skb = skb_dequeue(&sdata->u.ap.ps_bc_buf))) {
diff --git a/net/mac80211/tx.c b/net/mac80211/tx.c
index 5950e3a..ef182c9 100644
--- a/net/mac80211/tx.c
+++ b/net/mac80211/tx.c
@@ -2359,6 +2359,37 @@ struct sk_buff *ieee80211_beacon_get_tim(struct ieee80211_hw *hw,
}
EXPORT_SYMBOL(ieee80211_beacon_get_tim);
+struct sk_buff *ieee80211_proberesp_get(struct ieee80211_hw *hw,
+ struct ieee80211_vif *vif)
+{
+ struct ieee80211_if_ap *ap = NULL;
+ struct sk_buff *presp = NULL, *skb = NULL;
+ struct ieee80211_hdr *hdr;
+ struct ieee80211_sub_if_data *sdata = vif_to_sdata(vif);
+
+ if (sdata->vif.type != NL80211_IFTYPE_AP)
+ return NULL;
+
+ rcu_read_lock();
+
+ ap = &sdata->u.ap;
+ presp = rcu_dereference(ap->probe_resp);
+ if (!presp)
+ goto out;
+
+ skb = skb_copy(presp, GFP_ATOMIC);
+ if (!skb)
+ goto out;
+
+ hdr = (struct ieee80211_hdr *) skb->data;
+ memset(hdr->addr1, 0, sizeof(hdr->addr1));
+
+out:
+ rcu_read_unlock();
+ return skb;
+}
+EXPORT_SYMBOL(ieee80211_proberesp_get);
+
struct sk_buff *ieee80211_pspoll_get(struct ieee80211_hw *hw,
struct ieee80211_vif *vif)
{
diff --git a/net/mac80211/util.c b/net/mac80211/util.c
index a2d2f73..59a7b61 100644
--- a/net/mac80211/util.c
+++ b/net/mac80211/util.c
@@ -1213,7 +1213,8 @@ int ieee80211_reconfig(struct ieee80211_local *local)
ieee80211_bss_info_change_notify(sdata, changed);
break;
case NL80211_IFTYPE_AP:
- changed |= BSS_CHANGED_SSID |
+ changed |= BSS_CHANGED_AP_PROBE_RESP |
+ BSS_CHANGED_SSID |
BSS_CHANGED_BEACON |
BSS_CHANGED_BEACON_ENABLED;
ieee80211_bss_info_change_notify(sdata, changed);
--
1.7.1
On Sun, 2011-01-30 at 12:34 +0200, Arik Nemtsov wrote:
> > Wait, no, I don't get it -- what does the nl80211 API have to do with
> > how mac80211 manages it? I think for the nl80211 API the new command
> > doesn't make a whole lot of sense. What happens in mac80211 I don't
> > think matters much.
>
> I guess I misunderstood your original suggestion. Are you suggesting I
> put the probe resp as part of the NL80211_CMD_SET_BSS cmd?
> I'm ok with that.
Yes, that's what I was thinking.
johannes
On Sun, Jan 30, 2011 at 01:24:56PM +0200, Arik Nemtsov wrote:
> After discussing this with the wl12xx FW guys, it seems that:
> - WPS2 and P2P special cases are currently not handled in FW - the
> default template is always returned for probe requests
> - The AP currently always responds to a probe request
> - The AP currently never passes up probe requests
I'm not too surprised about the first two, but the last one is somewhat
unfortunate for WPS use in general.
> In light of this new info, this might be a possible solution:
> - Implement a capability flag for
> ap-supports-offloading-of-basic-probe-reqs. With "basic" I mean WPS1/2
> and P2P IEs are not included.
> - Hostapd will configure a probe-resp template only when it supports
> probe-resp offloading (currently when WPS and P2P are off) and the
> driver supports it (using the capability flag).
> - Support a "pass and and don't reply to probe requests" mode in FW
> (this will take some time to implement).
That sounds reasonable. Though, it would be useful to indicate the
no-probe-req-notifications or well, document that flag to mean that
Probe Request processing is pretty much black box with now visibility to
the host.
As far as the pass-don't-reply mode is concerned, how would that be
selected (once implemented)? Would that add a new capability flag and
configuration option, so that hostapd could decide to configure it if
the configuration is enabling WPS and not use it if WPS is disabled?
> For now the wl12xx driver must operate in a "compatibility" mode,
> since the FW doesn't support passing-up probe requests. When the
> probe-resp template is not available we will use the beacon template,
> as currently used now. There are currently no plans for intelligent
> filtering of probe requests in FW - its all or nothing.
OK.
> Should hostapd reply to probe requests when offloading is configured?
> This is a moot point for wl12xx since probe-requests are not passed
> up. Do you have a preference here?
So far, hostapd is prepared for the driver taking care of Probe Request
handling mainly in the case that all of MLME operations, i.e., including
authentication and association, are done in the firmware/driver. In this
case, there is a driver wrapper event (EVENT_RX_PROBE_REQ) that
indicates the received Probe Request frames for WPS processing without a
response coming back. If the Probe Request frame is indicated in a same
way as other management frames (monitor interface currently with
mac80211, but that is subject to change at some point), as response will
be sent. As such, this decision could be done in mac80211 (e.g., add a
new nl80211 event for notification-only-RX-probe-req which would be
mapped into EVENT_RX_PROBE_REQ).
Since there is not much extra processing needed for trying to generate
and transmit the Probe Response frames, I don't care much if the driver
then ends up dropping it in the offloading case. Though, I think I would
have slight preference on using the EVENT_RX_PROBE_REQ to avoid extra
processing.
--
Jouni Malinen PGP id EFC895FA
On Mon, 2011-01-24 at 22:47 +0200, Arik Nemtsov wrote:
> On Mon, Jan 24, 2011 at 13:35, Johannes Berg <[email protected]> wrote:
> > On Sun, 2011-01-23 at 23:02 +0200, Arik Nemtsov wrote:
> >> Allow usermode to pass probe-response data. This data can be used as a
> >> template probe-response offloading.
> >
> > Why use a separate command for this, and not do it like the SSID? I also
>
> Its only relevant to AP-mode (at least for now) so bss_conf didn't
> seem appropriate.
> Also since its a dynamically allocated buffer it should be protected by RCU.
But all that is unrelated to the nl80211 API, no? Also the SSID already
uses bss_conf too, and it's AP mode too...
> About compatibility - good point there. Currently the probe response
> template is set according to the beacon for compatibility. As for SSID
> - with the current wl12xx we'll set an empty SSID when a
> non-supporting hostapd is encountered. I'll fix that (in a v3). Other
> than that, we should be able to operate with either one configured.
Does that mean if you set an empty SSID it won't reply but pass them up?
Then you could implement the behaviour I just asked for ...
johannes
On Mon, 2011-01-24 at 23:21 +0200, Arik Nemtsov wrote:
> Well a wiphy flag won't do here. Probe requests may be filtered in
> some modes (AP-mode) but needed in others (p2p?).
> I think flexibility is a nice added bonus here. A FW can decide to
> handle most standard probe-requests and simply not pass them up.
> Others ("complicated" ones) it can pass up to hostapd and expect it to reply.
>
> The current patches leave this policy in the hands of the driver/fw.
That is _very_ dangerous. If the user has older firmware that doesn't
know about WSC2, how would the user know not to configure WSC2 in
hostapd? That needs to be known to hostapd so it can verify this
situation. For P2P, we already know whether or not P2P is supported, but
that's rather vague in case there will ever be a revision of the P2P
spec with say different IEs.
Additionally, a "regular AP" (not P2P, not WSC) would still want to
reply to probe requests from WSC/P2P devices with the normal template.
IMHO it would be smarter to rework the firmware to only reply to probe
requests if the probe response is configured. Then, if WSC, P2P, or
similar technologies are in use on the interface, hostapd can simply
decide to not configure the probe response and have host-based
processing. Would that be a change you could still make?
johannes
Detect whether our SSID is hidden by comparing beacon data with
the SSID in bss_conf.
Signed-off-by: Arik Nemtsov <[email protected]>
---
drivers/net/wireless/wl12xx/cmd.c | 23 ++++++++++-------------
1 files changed, 10 insertions(+), 13 deletions(-)
diff --git a/drivers/net/wireless/wl12xx/cmd.c b/drivers/net/wireless/wl12xx/cmd.c
index e28d9ca..7a6f39e 100644
--- a/drivers/net/wireless/wl12xx/cmd.c
+++ b/drivers/net/wireless/wl12xx/cmd.c
@@ -966,16 +966,6 @@ int wl1271_cmd_start_bss(struct wl1271 *wl)
wl1271_debug(DEBUG_CMD, "cmd start bss");
- /*
- * FIXME: We currently do not support hidden SSID. The real SSID
- * should be fetched from mac80211 first.
- */
- if (wl->ssid_len == 0) {
- wl1271_warning("Hidden SSID currently not supported for AP");
- ret = -EINVAL;
- goto out;
- }
-
cmd = kzalloc(sizeof(*cmd), GFP_KERNEL);
if (!cmd) {
ret = -ENOMEM;
@@ -993,9 +983,16 @@ int wl1271_cmd_start_bss(struct wl1271 *wl)
cmd->dtim_interval = bss_conf->dtim_period;
cmd->beacon_expiry = WL1271_AP_DEF_BEACON_EXP;
cmd->channel = wl->channel;
- cmd->ssid_len = wl->ssid_len;
- cmd->ssid_type = SSID_TYPE_PUBLIC;
- memcpy(cmd->ssid, wl->ssid, wl->ssid_len);
+
+ /* We use a visible SSID if the beacon SSID matches bss_conf */
+ if (wl->ssid_len > 0 && wl->ssid_len == bss_conf->ssid_len &&
+ !memcmp(wl->ssid, bss_conf->ssid, wl->ssid_len))
+ cmd->ssid_type = SSID_TYPE_PUBLIC;
+ else
+ cmd->ssid_type = SSID_TYPE_HIDDEN;
+
+ cmd->ssid_len = bss_conf->ssid_len;
+ memcpy(cmd->ssid, bss_conf->ssid, bss_conf->ssid_len);
switch (wl->band) {
case IEEE80211_BAND_2GHZ:
--
1.7.1
On Mon, Jan 24, 2011 at 13:38, Johannes Berg <[email protected]> wrote:
> On Sun, 2011-01-23 at 23:02 +0200, Arik Nemtsov wrote:
>
>> +static int ieee80211_set_probe_resp(struct wiphy *wiphy,
>> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? struct net_device *dev, u8 *resp,
>> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? size_t resp_len)
>> +{
>> + ? ? struct ieee80211_sub_if_data *sdata;
>> + ? ? struct sk_buff *new, *old;
>> +
>> + ? ? sdata = IEEE80211_DEV_TO_SUB_IF(dev);
>> + ? ? old = sdata->u.ap.probe_resp;
>> +
>> + ? ? if (!resp || !resp_len)
>> + ? ? ? ? ? ? return -EINVAL;
>> +
>> + ? ? new = dev_alloc_skb(resp_len);
>> + ? ? if (!new) {
>> + ? ? ? ? ? ? printk(KERN_DEBUG "%s: failed to allocate buffer for probe "
>> + ? ? ? ? ? ? ? ? ? ?"response template\n", sdata->name);
>> + ? ? ? ? ? ? return -ENOMEM;
>
> I'd remove that message -- userspace already knows, and it's the only
> thing that really needs to?
>
Sure. I'll fix this in v3 (somehow missed this email before).
Arik
On Tue, Jan 25, 2011 at 12:42, Johannes Berg <[email protected]> wrote:
> On Tue, 2011-01-25 at 11:10 +0100, Johannes Berg wrote:
>> On Mon, 2011-01-24 at 23:21 +0200, Arik Nemtsov wrote:
>>
>> > Well a wiphy flag won't do here. Probe requests may be filtered in
>> > some modes (AP-mode) but needed in others (p2p?).
>> > I think flexibility is a nice added bonus here. A FW can decide to
>> > handle most standard probe-requests and simply not pass them up.
>> > Others ("complicated" ones) it can pass up to hostapd and expect it to reply.
>> >
>> > The current patches leave this policy in the hands of the driver/fw.
>>
>> That is _very_ dangerous. If the user has older firmware that doesn't
>> know about WSC2, how would the user know not to configure WSC2 in
>> hostapd? That needs to be known to hostapd so it can verify this
>> situation. For P2P, we already know whether or not P2P is supported, but
>> that's rather vague in case there will ever be a revision of the P2P
>> spec with say different IEs.
>>
>> Additionally, a "regular AP" (not P2P, not WSC) would still want to
>> reply to probe requests from WSC/P2P devices with the normal template.
>>
>> IMHO it would be smarter to rework the firmware to only reply to probe
>> requests if the probe response is configured. Then, if WSC, P2P, or
>> similar technologies are in use on the interface, hostapd can simply
>> decide to not configure the probe response and have host-based
>> processing. Would that be a change you could still make?
>
>
> Of course, firmware can reply to non-p2p/non-wsc2 probe requests with a
> static probe response template.
>
> The question is how much knowledge you want to put into the firmware
> about those protocols. If you want to put all knowledge in there, then
> at least you need to indicate to hostapd which protocols the firmware
> knows not to reply to.
>
> Also, a way to turn off this behaviour would still be good for future
> protocol changes. If P2P changes in 3 years, I'm sure this firmware
> won't be updated to match since you'll be a few hardware generations
> ahead. Then, being able to turn off the offload completely would allow
> users to take advantage of new protocols without changing hardware. Of
> course, you may want to force users to buy new hardware that way -- but
> in that case we *still* need the advertisement of what's possible so
> users know right away that they need to buy new hardware and don't try
> to configure something that just fails in strange ways.
>
Like I said in a previous email - I think a white list (or black list)
of IEs in FW is the way to go here. Not all probe-responses should be
offloaded.
Its also conceivable that an old driver/fw won't work when some
protocol is changed/updated, even if hostapd supports it.
I'm not sure the probe-resp will be the culprit here..
Arik
On Sun, 2011-01-23 at 23:02 +0200, Arik Nemtsov wrote:
> Allow usermode to pass probe-response data. This data can be used as a
> template probe-response offloading.
Why use a separate command for this, and not do it like the SSID? I also
was under the impression you wanted both (which is somewhat redundant
since you can parse the SSID out of the probe response), so shouldn't
they both be required (or none, for compatibility)?
Also, should cfg80211 pretend it knows the SSID/probe response when
userspace didn't set it (from the beacon) so that mac80211 or the
low-level drivers don't need to worry?
johannes
On Tue, Jan 25, 2011 at 11:41, Jouni Malinen <[email protected]> wrote:
> On Mon, Jan 24, 2011 at 11:16:43PM +0200, Arik Nemtsov wrote:
>> The SSID-as-attr not used for the probe-resp template. It is used by
>> FW to filter out which probe-reqs should be responded to when
>> operating with a hidden SSID.
>
> OK, that would be useful to mention in nl80211.h comments and
> cfg80211.h, too, I'd guess.
Sure. I'll put in a few words.
>
>> The wl12xx FW updates the timestamp and DA. I mentioned in the
>> documentation of ieee80211_proberesp_get (and various other parts)
>> that the DA should be set manually and that this should be used as a
>> template (which also implies timestamp should be set). If some part is
>> unclear can you point out a specific patch?
>
> DA should be pretty obvious. Timestamp is something that I hope is clear
> for whoever is implementing a driver, but it could be mentioned
> somewhere.
Sure.
>
>> Perhaps we can start with these AP-mode only patches and expand the
>> functionality when it is needed for p2p?
>
> I'm fine with them if there is a capability flag that allows user space
> to know that the driver does not use user space -based Probe Request
> processing. With that, hostapd/wpa_supplicant can disable functionality
> like multi-SSID support, WPS 2.0, P2P until we get more complete
> capability information on what devices that process Probe Request frames
> internally can do.
Makes sense. I'll look into it.
Arik
On Sun, Jan 30, 2011 at 20:37, Jouni Malinen <[email protected]> wrote:
>
> That sounds reasonable. Though, it would be useful to indicate the
> no-probe-req-notifications or well, document that flag to mean that
> Probe Request processing is pretty much black box with now visibility to
> the host.
Will do.
>
> As far as the pass-don't-reply mode is concerned, how would that be
> selected (once implemented)? Would that add a new capability flag and
> configuration option, so that hostapd could decide to configure it if
> the configuration is enabling WPS and not use it if WPS is disabled?
I was thinking hostapd would simply not configure a probe-resp
template when offloading is disabled. In essence probe-resp offloading
will be disabled by default, and can be enabled only by pushing the
probe resp template.
Upon seeing the probe-resp template change notification, the low level
driver will enable offloading.
>
>> Should hostapd reply to probe requests when offloading is configured?
>> This is a moot point for wl12xx since probe-requests are not passed
>> up. Do you have a preference here?
>
> So far, hostapd is prepared for the driver taking care of Probe Request
> handling mainly in the case that all of MLME operations, i.e., including
> authentication and association, are done in the firmware/driver. In this
> case, there is a driver wrapper event (EVENT_RX_PROBE_REQ) that
> indicates the received Probe Request frames for WPS processing without a
> response coming back. If the Probe Request frame is indicated in a same
> way as other management frames (monitor interface currently with
> mac80211, but that is subject to change at some point), as response will
> be sent. As such, this decision could be done in mac80211 (e.g., add a
> new nl80211 event for notification-only-RX-probe-req which would be
> mapped into EVENT_RX_PROBE_REQ).
>
Does indicate-up-and-reply make sense from a power-save perspective?
The main goal of probe-resp offloading is not to wake up the host. If
the host is woken up by the indication, it might as well answer the
probe request.
This intermediate case is not currently implemented in wl12xx. Is
there a good reason to implement it?
Also with current wl12xx FW there's no way to test this code (probe
requests are never passed up). Perhaps we can start with the hostapd
rejecting probe requests in probe-resp offloading mode, and implement
the intermediate case later on?
Arik
On Mon, Jan 24, 2011 at 11:16:43PM +0200, Arik Nemtsov wrote:
> The SSID-as-attr not used for the probe-resp template. It is used by
> FW to filter out which probe-reqs should be responded to when
> operating with a hidden SSID.
OK, that would be useful to mention in nl80211.h comments and
cfg80211.h, too, I'd guess.
> The wl12xx FW updates the timestamp and DA. I mentioned in the
> documentation of ieee80211_proberesp_get (and various other parts)
> that the DA should be set manually and that this should be used as a
> template (which also implies timestamp should be set). If some part is
> unclear can you point out a specific patch?
DA should be pretty obvious. Timestamp is something that I hope is clear
for whoever is implementing a driver, but it could be mentioned
somewhere.
> For WPS (without p2p), it appears the probe-resp doesn't depend on the
> probe-req (in hostapd code).
This is the case for WPS 1.0, but the protocol update in WSC 2.0 does
introduce a dependency.
> Perhaps we can start with these AP-mode only patches and expand the
> functionality when it is needed for p2p?
I'm fine with them if there is a capability flag that allows user space
to know that the driver does not use user space -based Probe Request
processing. With that, hostapd/wpa_supplicant can disable functionality
like multi-SSID support, WPS 2.0, P2P until we get more complete
capability information on what devices that process Probe Request frames
internally can do.
> Note that the current patch doesn't remove existing functionality - a
> driver/FW operating in p2p mode can simply choose not to use the
> template and just pass probe-requests up.
Until now, I've been assuming that nl80211-based interface means that
Probe Request frames are handled in user space. Since this set of
patches makes it very obvious that that will not be the case, I do want
to be able to figure that out in user space easily. All it really takes
is to add a capability flag indicating whether user space -based Probe
Request processing is used or not.
--
Jouni Malinen PGP id EFC895FA
On Sun, 2011-01-23 at 23:02 +0200, Arik Nemtsov wrote:
> Support passing SSID and probe-response template to drivers.
> This data can be used to offload the beacon -> probe-req -> probe-resp
> process to HW.
I still think you should add a wiphy flag and advertise it in nl80211 to
advertise and request this behaviour. That will allow hostapd (and
mac80211 in IBSS mode) to not reply to probe requests when they aren't
filtered out by the device, and will allow hostapd/wpa_s to also
restrict its operation to non-P2P etc. as Jouni pointed out. For P2P
then that will have to be extended more I guess, and the firmware
functionality be improved -- or even disabled.
johannes
On Wed, Jan 26, 2011 at 08:08, Arik Nemtsov <[email protected]> wrote:
> On Tue, Jan 25, 2011 at 11:41, Jouni Malinen <[email protected]> wrote:
>> On Mon, Jan 24, 2011 at 11:16:43PM +0200, Arik Nemtsov wrote:
>>> The SSID-as-attr not used for the probe-resp template. It is used by
>>> FW to filter out which probe-reqs should be responded to when
>>> operating with a hidden SSID.
>>
>> OK, that would be useful to mention in nl80211.h comments and
>> cfg80211.h, too, I'd guess.
>
> Sure. I'll put in a few words.
>
>>
>>> The wl12xx FW updates the timestamp and DA. I mentioned in the
>>> documentation of ieee80211_proberesp_get (and various other parts)
>>> that the DA should be set manually and that this should be used as a
>>> template (which also implies timestamp should be set). If some part is
>>> unclear can you point out a specific patch?
>>
>> DA should be pretty obvious. Timestamp is something that I hope is clear
>> for whoever is implementing a driver, but it could be mentioned
>> somewhere.
>
> Sure.
>
>>
>>> Perhaps we can start with these AP-mode only patches and expand the
>>> functionality when it is needed for p2p?
>>
>> I'm fine with them if there is a capability flag that allows user space
>> to know that the driver does not use user space -based Probe Request
>> processing. With that, hostapd/wpa_supplicant can disable functionality
>> like multi-SSID support, WPS 2.0, P2P until we get more complete
>> capability information on what devices that process Probe Request frames
>> internally can do.
>
> Makes sense. I'll look into it.
>
Just to clear up - I don't want to disable p2p or wps support in
hostapd if probe-resp offloading is configured. The low level
driver/fw could realistically differentiate between regular and
non-support probe requests, and only handle the former.
The kind of capability flag you asked won't work with such a low lever
driver/fw combo. Is muti-ssid support currently implemented?
How about a different solution - I'll just disable p2p IEs for the
probe-resp template for now. Let's assume the FW behaves correctly in
this case and passes up the probe-requests. The code for generating
the WPS IE for the probe-resp seems to not depend on the probe-req. Is
the feature of WPS 2.0 you mentioned currently implemented? If so this
can be disabled as well.
Arik
On Wed, 2011-01-26 at 23:51 +0200, Arik Nemtsov wrote:
> > What's wrong with putting it in the same place as the SSID?
>
> Just put it as a pointer inside ieee80211_bss_conf? (It will still
> have to be RCU managed and all).
> About nl80211 API - I tried making it as similar as possible to the
> way the beacon works, but I guess I can pass it with bss_parameters as
> well.
Ok. Let me look at it again tomorrow.
johannes
On Sun, Jan 23, 2011 at 11:02:53PM +0200, Arik Nemtsov wrote:
> Support passing SSID and probe-response template to drivers.
> This data can be used to offload the beacon -> probe-req -> probe-resp
> process to HW.
What is the expected driver behavior for passing the SSID as a separate
attribute vs. passing the SSID as an IE within the Probe Response
template? Is the SSID-as-attr ever used to fill in a Probe Response by
the driver/firmware? Or is the driver/firmware only allowed to use the
full Probe Response template (with DA and timestamp updated)? It would
be useful to get this documented so that it is clear for people working
with both a driver and user space applications that could use the new
interface.
We should also document the need for special Probe Request processing
for WPS and P2P and have capability flags indicating whether the driver
needs the SSID and/or Probe Response template and whether it supports
various special rules for Probe Request processing (remove P2P IE from
Probe Response template if Probe Request does not include it, do not
reply to Probe Request if there is no match for Requested Device Type,
do not reply if there is no match for P2P Device Address). hostapd (or
wpa_supplicant AP mode) would then automatically disable use of P2P
and/or WPS if the driver/firmware does not have necessary capabilities
to implement this correctly.
--
Jouni Malinen PGP id EFC895FA
On Wed, 2011-01-26 at 08:00 +0200, Arik Nemtsov wrote:
> >> > Why use a separate command for this, and not do it like the SSID? I also
> >>
> >> Its only relevant to AP-mode (at least for now) so bss_conf didn't
> >> seem appropriate.
> >> Also since its a dynamically allocated buffer it should be protected by RCU.
> >
> > But all that is unrelated to the nl80211 API, no? Also the SSID already
> > uses bss_conf too, and it's AP mode too...
>
> Do you have a preferred alternative?
What's wrong with putting it in the same place as the SSID?
johannes
On Thu, Jan 27, 2011 at 15:29, Johannes Berg <[email protected]> wrote:
> On Wed, 2011-01-26 at 23:51 +0200, Arik Nemtsov wrote:
>> On Wed, Jan 26, 2011 at 10:32, Johannes Berg <[email protected]> wrote:
>> > On Wed, 2011-01-26 at 08:00 +0200, Arik Nemtsov wrote:
>> >
>> >> >> > Why use a separate command for this, and not do it like the SSID? I also
>> >> >>
>> >> >> Its only relevant to AP-mode (at least for now) so bss_conf didn't
>> >> >> seem appropriate.
>> >> >> Also since its a dynamically allocated buffer it should be protected by RCU.
>> >> >
>> >> > But all that is unrelated to the nl80211 API, no? Also the SSID already
>> >> > uses bss_conf too, and it's AP mode too...
>> >>
>> >> Do you have a preferred alternative?
>> >
>> > What's wrong with putting it in the same place as the SSID?
>>
>> Just put it as a pointer inside ieee80211_bss_conf? (It will still
>> have to be RCU managed and all).
>> About nl80211 API - I tried making it as similar as possible to the
>> way the beacon works, but I guess I can pass it with bss_parameters as
>> well.
>
> Wait, no, I don't get it -- what does the nl80211 API have to do with
> how mac80211 manages it? I think for the nl80211 API the new command
> doesn't make a whole lot of sense. What happens in mac80211 I don't
> think matters much.
I guess I misunderstood your original suggestion. Are you suggesting I
put the probe resp as part of the NL80211_CMD_SET_BSS cmd?
I'm ok with that.
Arik
On Mon, Jan 24, 2011 at 11:44, Jouni Malinen <[email protected]> wrote:
> On Sun, Jan 23, 2011 at 11:02:53PM +0200, Arik Nemtsov wrote:
>> Support passing SSID and probe-response template to drivers.
>> This data can be used to offload the beacon -> probe-req -> probe-resp
>> process to HW.
>
> What is the expected driver behavior for passing the SSID as a separate
> attribute vs. passing the SSID as an IE within the Probe Response
> template? Is the SSID-as-attr ever used to fill in a Probe Response by
> the driver/firmware? Or is the driver/firmware only allowed to use the
> full Probe Response template (with DA and timestamp updated)? It would
> be useful to get this documented so that it is clear for people working
> with both a driver and user space applications that could use the new
> interface.
The SSID-as-attr not used for the probe-resp template. It is used by
FW to filter out which probe-reqs should be responded to when
operating with a hidden SSID.
The wl12xx FW updates the timestamp and DA. I mentioned in the
documentation of ieee80211_proberesp_get (and various other parts)
that the DA should be set manually and that this should be used as a
template (which also implies timestamp should be set). If some part is
unclear can you point out a specific patch?
>
> We should also document the need for special Probe Request processing
> for WPS and P2P and have capability flags indicating whether the driver
> needs the SSID and/or Probe Response template and whether it supports
> various special rules for Probe Request processing (remove P2P IE from
> Probe Response template if Probe Request does not include it, do not
> reply to Probe Request if there is no match for Requested Device Type,
> do not reply if there is no match for P2P Device Address). hostapd (or
> wpa_supplicant AP mode) would then automatically disable use of P2P
> and/or WPS if the driver/firmware does not have necessary capabilities
> to implement this correctly.
>
For WPS (without p2p), it appears the probe-resp doesn't depend on the
probe-req (in hostapd code).
I also explicitly made sure this scenario works since this is a good
example for a use-case when the probe-response is different from the
beacon.
Perhaps we can start with these AP-mode only patches and expand the
functionality when it is needed for p2p?
It may be hard to predict what other special handling will be needed
for offloading p2p probe-resps to FW (when such FW is available).
Note that the current patch doesn't remove existing functionality - a
driver/FW operating in p2p mode can simply choose not to use the
template and just pass probe-requests up.
Regards,
Arik
On Sun, 2011-01-23 at 23:02 +0200, Arik Nemtsov wrote:
> +static int ieee80211_set_probe_resp(struct wiphy *wiphy,
> + struct net_device *dev, u8 *resp,
> + size_t resp_len)
> +{
> + struct ieee80211_sub_if_data *sdata;
> + struct sk_buff *new, *old;
> +
> + sdata = IEEE80211_DEV_TO_SUB_IF(dev);
> + old = sdata->u.ap.probe_resp;
> +
> + if (!resp || !resp_len)
> + return -EINVAL;
> +
> + new = dev_alloc_skb(resp_len);
> + if (!new) {
> + printk(KERN_DEBUG "%s: failed to allocate buffer for probe "
> + "response template\n", sdata->name);
> + return -ENOMEM;
I'd remove that message -- userspace already knows, and it's the only
thing that really needs to?
> + }
> +
> + memcpy(skb_put(new, resp_len), resp, resp_len);
> +
> + rcu_assign_pointer(sdata->u.ap.probe_resp, new);
> + synchronize_rcu();
> +
> + if (old)
> + dev_kfree_skb(old);
Just a note -- I don't really expect you to implement this -- but I
think since the skb's CB is not used otherwise, we could easily use
call_rcu() to free it.
johannes
On Tue, 2011-01-25 at 11:10 +0100, Johannes Berg wrote:
> On Mon, 2011-01-24 at 23:21 +0200, Arik Nemtsov wrote:
>
> > Well a wiphy flag won't do here. Probe requests may be filtered in
> > some modes (AP-mode) but needed in others (p2p?).
> > I think flexibility is a nice added bonus here. A FW can decide to
> > handle most standard probe-requests and simply not pass them up.
> > Others ("complicated" ones) it can pass up to hostapd and expect it to reply.
> >
> > The current patches leave this policy in the hands of the driver/fw.
>
> That is _very_ dangerous. If the user has older firmware that doesn't
> know about WSC2, how would the user know not to configure WSC2 in
> hostapd? That needs to be known to hostapd so it can verify this
> situation. For P2P, we already know whether or not P2P is supported, but
> that's rather vague in case there will ever be a revision of the P2P
> spec with say different IEs.
>
> Additionally, a "regular AP" (not P2P, not WSC) would still want to
> reply to probe requests from WSC/P2P devices with the normal template.
>
> IMHO it would be smarter to rework the firmware to only reply to probe
> requests if the probe response is configured. Then, if WSC, P2P, or
> similar technologies are in use on the interface, hostapd can simply
> decide to not configure the probe response and have host-based
> processing. Would that be a change you could still make?
Of course, firmware can reply to non-p2p/non-wsc2 probe requests with a
static probe response template.
The question is how much knowledge you want to put into the firmware
about those protocols. If you want to put all knowledge in there, then
at least you need to indicate to hostapd which protocols the firmware
knows not to reply to.
Also, a way to turn off this behaviour would still be good for future
protocol changes. If P2P changes in 3 years, I'm sure this firmware
won't be updated to match since you'll be a few hardware generations
ahead. Then, being able to turn off the offload completely would allow
users to take advantage of new protocols without changing hardware. Of
course, you may want to force users to buy new hardware that way -- but
in that case we *still* need the advertisement of what's possible so
users know right away that they need to buy new hardware and don't try
to configure something that just fails in strange ways.
johannes
When operating as AP, save SSID data as part of the ieee80211_bss_conf
struct. Allow low level drivers to receive notifications about SSID
changes.
Signed-off-by: Arik Nemtsov <[email protected]>
---
include/net/mac80211.h | 6 ++++++
net/mac80211/cfg.c | 7 +++++++
net/mac80211/util.c | 7 ++++++-
3 files changed, 19 insertions(+), 1 deletions(-)
diff --git a/include/net/mac80211.h b/include/net/mac80211.h
index 62c0ce2..ff3bad1 100644
--- a/include/net/mac80211.h
+++ b/include/net/mac80211.h
@@ -164,6 +164,7 @@ struct ieee80211_low_level_stats {
* @BSS_CHANGED_QOS: QoS for this association was enabled/disabled. Note
* that it is only ever disabled for station mode.
* @BSS_CHANGED_IDLE: Idle changed for this BSS/interface.
+ * @BSS_CHANGED_SSID: SSID changed for this BSS (AP mode)
*/
enum ieee80211_bss_change {
BSS_CHANGED_ASSOC = 1<<0,
@@ -181,6 +182,7 @@ enum ieee80211_bss_change {
BSS_CHANGED_ARP_FILTER = 1<<12,
BSS_CHANGED_QOS = 1<<13,
BSS_CHANGED_IDLE = 1<<14,
+ BSS_CHANGED_SSID = 1<<15,
/* when adding here, make sure to change ieee80211_reconfig */
};
@@ -243,6 +245,8 @@ enum ieee80211_bss_change {
* @idle: This interface is idle. There's also a global idle flag in the
* hardware config which may be more appropriate depending on what
* your driver/device needs to do.
+ * @ssid_len: Length of @ssid in octets (in AP mode)
+ * @ssid: SSID for this BSS (in AP mode)
*/
struct ieee80211_bss_conf {
const u8 *bssid;
@@ -269,6 +273,8 @@ struct ieee80211_bss_conf {
bool arp_filter_enabled;
bool qos;
bool idle;
+ u8 ssid_len;
+ u8 ssid[IEEE80211_MAX_SSID_LEN];
};
/**
diff --git a/net/mac80211/cfg.c b/net/mac80211/cfg.c
index 4bc8a92..a2a75e9 100644
--- a/net/mac80211/cfg.c
+++ b/net/mac80211/cfg.c
@@ -1172,6 +1172,13 @@ static int ieee80211_change_bss(struct wiphy *wiphy,
changed |= BSS_CHANGED_HT;
}
+ if (params->ssid_len > 0) {
+ memcpy(sdata->vif.bss_conf.ssid, params->ssid,
+ params->ssid_len);
+ sdata->vif.bss_conf.ssid_len = params->ssid_len;
+ changed |= BSS_CHANGED_SSID;
+ }
+
ieee80211_bss_info_change_notify(sdata, changed);
return 0;
diff --git a/net/mac80211/util.c b/net/mac80211/util.c
index cf68700..a2d2f73 100644
--- a/net/mac80211/util.c
+++ b/net/mac80211/util.c
@@ -1212,10 +1212,15 @@ int ieee80211_reconfig(struct ieee80211_local *local)
changed |= BSS_CHANGED_ASSOC;
ieee80211_bss_info_change_notify(sdata, changed);
break;
+ case NL80211_IFTYPE_AP:
+ changed |= BSS_CHANGED_SSID |
+ BSS_CHANGED_BEACON |
+ BSS_CHANGED_BEACON_ENABLED;
+ ieee80211_bss_info_change_notify(sdata, changed);
+ break;
case NL80211_IFTYPE_ADHOC:
changed |= BSS_CHANGED_IBSS;
/* fall through */
- case NL80211_IFTYPE_AP:
case NL80211_IFTYPE_MESH_POINT:
changed |= BSS_CHANGED_BEACON |
BSS_CHANGED_BEACON_ENABLED;
--
1.7.1
On Mon, Jan 24, 2011 at 11:21:44PM +0200, Arik Nemtsov wrote:
> Well a wiphy flag won't do here. Probe requests may be filtered in
> some modes (AP-mode) but needed in others (p2p?).
> I think flexibility is a nice added bonus here. A FW can decide to
> handle most standard probe-requests and simply not pass them up.
> Others ("complicated" ones) it can pass up to hostapd and expect it to reply.
Hmm.. So would the design be that upper layers (mac80211/hostapd) would
not see the Probe Request frames that the firmware replies to? What
would be criteria in selecting what is a "standard" and what is a
"complicated" Probe Request?
One thing that came up when I was thinking about a bit more is that even
with WPS 1.0, the Probe Request frames with WSC IE must be passed up to
hostapd for PBC session overlap detection and to support external
Registrars. So even if you could reply to those Probe Request frames in
firmware, they would still need to be indicated to hostapd and hostapd
(or something else in the system) would need to know that a duplicated
response should not be sent. Similar needs for receiving Probe Request
frames apply for P2P and potentially for some other protocols, too.
What is the main point of replying to Probe Request frames in the
firmware? Reduced latency? Reduced power consumption of the host CPU?
Something else? The former could be achieved even if the frame were
passed up; the latter would be difficult to achieve if WPS or P2P is
enabled without implementing large part of the protocol in the
firmware..
--
Jouni Malinen PGP id EFC895FA
On Wed, Jan 26, 2011 at 10:32, Johannes Berg <[email protected]> wrote:
> On Wed, 2011-01-26 at 08:00 +0200, Arik Nemtsov wrote:
>
>> >> > Why use a separate command for this, and not do it like the SSID? I also
>> >>
>> >> Its only relevant to AP-mode (at least for now) so bss_conf didn't
>> >> seem appropriate.
>> >> Also since its a dynamically allocated buffer it should be protected by RCU.
>> >
>> > But all that is unrelated to the nl80211 API, no? Also the SSID already
>> > uses bss_conf too, and it's AP mode too...
>>
>> Do you have a preferred alternative?
>
> What's wrong with putting it in the same place as the SSID?
Just put it as a pointer inside ieee80211_bss_conf? (It will still
have to be RCU managed and all).
About nl80211 API - I tried making it as similar as possible to the
way the beacon works, but I guess I can pass it with bss_parameters as
well.
Arik