[PATCH 2/2] wnm: Add neigh ies to bss transition mgt request

Janusz Dziedzic janusz.dziedzic at gmail.com
Mon Apr 1 04:16:00 PDT 2019


niedz., 31 mar 2019 o 17:17 Ben Greear <greearb at candelatech.com> napisał(a):
>
>
>
> On 03/31/2019 01:01 AM, Janusz Dziedzic wrote:
> > czw., 21 mar 2019 o 15:33 <greearb at candelatech.com> napisał(a):
> >>
> >> From: Ben Greear <greearb at candelatech.com>
> >>
> >> If a station requests a bss transition, then send add any
> >> configured neighbors to the response.
> >>
> >> Signed-off-by: Ben Greear <greearb at candelatech.com>
> >> ---
> >>  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 at candelatech.com>
> Candela Technologies Inc  http://www.candelatech.com



-- 
Janusz Dziedzic



More information about the Hostap mailing list