On 04/01/2019 04:16 AM, Janusz Dziedzic wrote:
niedz., 31 mar 2019 o 17:17 Ben Greear <greearb@xxxxxxxxxxxxxxx> napisał(a):
On 03/31/2019 01:01 AM, Janusz Dziedzic wrote:
czw., 21 mar 2019 o 15:33 <greearb@xxxxxxxxxxxxxxx> napisał(a):
From: Ben Greear <greearb@xxxxxxxxxxxxxxx>
If a station requests a bss transition, then send add any
configured neighbors to the response.
Signed-off-by: Ben Greear <greearb@xxxxxxxxxxxxxxx>
---
src/ap/wnm_ap.c | 25 ++++++++++++++++++++++++-
1 file changed, 24 insertions(+), 1 deletion(-)
diff --git a/src/ap/wnm_ap.c b/src/ap/wnm_ap.c
index 27c69d3..cef44ce 100644
--- a/src/ap/wnm_ap.c
+++ b/src/ap/wnm_ap.c
@@ -345,8 +345,9 @@ static int ieee802_11_send_bss_trans_mgmt_request(struct hostapd_data *hapd,
size_t len;
u8 *pos;
int res;
+ struct wpabuf *buf;
- mgmt = os_zalloc(sizeof(*mgmt));
+ mgmt = os_zalloc(IEEE80211_MAX_MMPDU_SIZE);
if (mgmt == NULL)
return -1;
os_memcpy(mgmt->da, addr, ETH_ALEN);
@@ -357,11 +358,33 @@ static int ieee802_11_send_bss_trans_mgmt_request(struct hostapd_data *hapd,
mgmt->u.action.category = WLAN_ACTION_WNM;
mgmt->u.action.u.bss_tm_req.action = WNM_BSS_TRANS_MGMT_REQ;
mgmt->u.action.u.bss_tm_req.dialog_token = dialog_token;
+ /* set 0x1 flag for prefered candidate list included.
+ * see: 9.6.14.9 BSS Transition Management Request frame format
+ */
mgmt->u.action.u.bss_tm_req.req_mode = 0;
mgmt->u.action.u.bss_tm_req.disassoc_timer = host_to_le16(0);
mgmt->u.action.u.bss_tm_req.validity_interval = 1;
pos = mgmt->u.action.u.bss_tm_req.variable;
+ buf = wpabuf_alloc(IEEE80211_MAX_MMPDU_SIZE - sizeof(*mgmt));
+ if (buf) {
+ /* Grab neighbor list */
+ /* TODO: Maybe round-robin and only send one?
+ * Or take load into consideration?
+ * Maybe we should skip our own entry?
+ */
+ int lci = 1; /* add lci sub-element */
+ int civic = 1; /* add civic sub-element */
+ int lci_age = 0xffff; /* maximum age, send all */
+ hostapd_rrm_add_neigh_report_ies(hapd, buf, NULL, lci, civic, lci_age);
+ if (wpabuf_len(buf)) {
+ mgmt->u.action.u.bss_tm_req.req_mode = 0x1;
+ os_memcpy(pos, wpabuf_head(buf), wpabuf_len(buf));
+ pos += wpabuf_len(buf);
+ }
+ wpabuf_free(buf);
+ }
+
wpa_printf(MSG_DEBUG, "WNM: Send BSS Transition Management Request to "
MACSTR " dialog_token=%u req_mode=0x%x disassoc_timer=%u "
"validity_interval=%u",
--
2.7.5
What if we have 3-4 (our bss) neighbors and we know all of them have
high loads (slow path). In such case I would setup only 1 bssid in BTM
request.
After your patch, we will have to remove_neighors before BTM req.
After we will remove them and other sta will send us neighbor report
request we will send only
one? Not sure how much this BTM is used for steering, but seems that
setting bssids form wpa_cli we had before your patch is better (or we
should not close this path), while we will not affect NRResp and could
build any BTM we need.
Maybe we should add switch for CLI BTM command - to include neighbors
or just get them from CLI?
From other side we still have BTM query (and this should base on neigh
database)?
Finally for multi AP solutions, maybe we should not handle this in
hostapd at all.
Just expose 11v/k action frames to upper layer (some manager that know
status of all APs) and also allow this manager to /send frames... Not
sure what is the best.
I was thinking we should also have a priority setting in the neigh DB,
so then when we send the neigh report, we can add the IE that specifies
the neighbor that is 'best' for the neighbor.
I did not see any way to add neighbors before my patch, can you show
the commands you use to implement this without my patch?
for btm check test_wnm.py
hapd.request("BSS_TM_REQ " + addr + "
neighbor=11:22:33:44:55:66,0x0000,81,3,7"):
From what I can tell, this is hostapd sending the request to the STA
based on outside event (ie, the .py script), and it seems that it is
building the packet directly there in the .py script.
My patch is used in the case where the STA makes a request to the AP,
and then the AP answers with a TM REQ. Before my patch, the answering
TM REQ had no neighbors, so it is mostly worthless as far as I can tell.
And in general, you probably do want this to be handled by a manager
that has better over-all insight. If you had a sniffer on all APs,
you could probably know RSSI to the requesting station for all APs,
and then you could steer the station to the AP with good RSSI (as well
as take load into account and such). In general, if you have an AP
with good RSSI and moderate load, that would be a better choice than
a very lightly loaded AP with poor RSSI.
Are there any open-source managers for hostapd APs?
Probably not :)
Someone should get on that! Looks like a great opportunity to learn how
to do tricky things in a distributed flaky RF environment with drivers
and firmware and radios of questionable quality up and down the stack!
Thanks,
Ben
--
Ben Greear <greearb@xxxxxxxxxxxxxxx>
Candela Technologies Inc http://www.candelatech.com
_______________________________________________
Hostap mailing list
Hostap@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/hostap
