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.5What 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? 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? 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
