pon., 1 kwi 2019 o 14:39 Ben Greear <greearb@xxxxxxxxxxxxxxx> napisał(a):
>
>
>
> 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.
>
So, this is for BSS TM query handling only.
Thanks for patch, seems another one will go to my tree.
BR
Janusz
> >> 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
--
Janusz Dziedzic
_______________________________________________
Hostap mailing list
Hostap@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/hostap
