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

Ben Greear greearb at candelatech.com
Mon Apr 1 05:39:03 PDT 2019



On 04/01/2019 04:16 AM, Janusz Dziedzic wrote:
> 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"):

 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 at candelatech.com>
Candela Technologies Inc  http://www.candelatech.com



More information about the Hostap mailing list