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"):
> 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 :)
> Thanks,
> Ben
>
>
> --
> Ben Greear <greearb@xxxxxxxxxxxxxxx>
> Candela Technologies Inc http://www.candelatech.com
--
Janusz Dziedzic
_______________________________________________
Hostap mailing list
Hostap@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/hostap
