Hi Ben: On Thu, Mar 14, 2019 at 6:45 AM Ben Greear <greearb@xxxxxxxxxxxxxxx> wrote: > > > > On 03/13/2019 06:51 PM, Dennis Bland wrote: > > Hi Ben: > > > > You need one STA and at least two APs (preferably on two different > > channels) to make 802.11k/v test cases. This is because Neighbor > > Reports are not very useful with only one AP (the connected AP), and > > 802.11v Transition Management requires at least two APs for non-MBO > > operation. > > > > While hostapd and wpa_supplicant contain most of the protocol-level > > functionality to send and parse the required elements in 802.11 > > management frames to support 802.11k/v, the logic implementation is > > not complete. For example, an AP central controller will send Beacon > > Report requests to a STA through different APs, then analyze the > > results to consider sending an 802.11v Transition Management request > > to the STA. > > > > At this time, Neighbor Report requests are sent periodically by > > wpa_supplicant, but Beacon Report requests (and Link Measurement > > requests) need to manually triggered in hostapd, as well as 802.11v TM > > requests. I guess we need something similar to the existing 802.11r > > "roam" and "ft_ds" CLI commands. To see the action frame activity > > without a packet sniffer, your test script can filter out the "RRM:" > > and "WNM:" results from the hostapd/supplicant log (with -dd enabled). > > > > Also note that if the WLAN chipset (e.g. ath9k/10k) is in firmware > > offload mode, the behavior may be different, and you may not see any > > action frames unless the RCPI drops below a certain threshold. > > Hello, > > Thanks for the information. I was thinking that maybe I could trigger > the station to send neigh report requests, see the output in 'wpa_cli' > listener mode, and then have a higher level program instigate a roam as > needed based on the wpa_cli output. That hasn't been implemented yet, but could be useful for automated test beds where the STA does not roam on its own. For STAs that roam automatically, the STA typically uses the Neighbor Report to reduce the number of channels it needs to scan in the background when considering a roam to another AP (e.g. if the RCPI of the current AP becomes weaker than -70 dBm). > > While watching a sniffer, I didn't see supplicant send any neigh reports > w/out me asking it to specifically with wpa_cli, but maybe I didn't > wait long enough. Or, do I need to specifically enable the feature > in the supplicant .conf file? You are right - I forgot our application was calling wpas_rrm_send_neighbor_rep_request() periodically. > > I don't think ath10k will be offloading this, at last the pci chipsets, > but if that does seem to be the case, then I can likely deal with it. > > Do I need to configure the hostapd instances so that they know they are > a group? Otherwise, how do they know if they are neighbors or not? hostapd implements an AP neighbor database (neighbor_db.c) that allows you to add AP neighbors with the 'set_neighbor' and 'remove_neighbor' CLI commands (with rrm_neighbor_report=1 in the .conf file). Higher-level logic to periodically scan for nearby APs, filter for neighbors within the same ESS, and build a neighbor list isn't implemented. > > Thanks, > Ben > > > > > Best regards, > > > > Dennis > > > > > > > > > > I'm trying to build some test APs and stations to do some experimenting with > > 802.11k/v features. > > > > Currently I have exactly one hostapd AP and one station. > > > > When I sniff the air, I see neighbor report requests and responses, > > for instance, but the wpa_cli output is a bit sparse: > > > > # ./local/bin/wpa_cli -i sta300 neighbor_rep_request > > OK > > > > Does anyone have an info on how to build a more useful test bed? Previously > > we built a cluster of APs to do .11r roaming, do I need to do that sort of thing > > to get interesting neigh report/requests to happen? > > > > Thanks, > > Ben > > > > _______________________________________________ > > Hostap mailing list > > Hostap@xxxxxxxxxxxxxxxxxxx > > http://lists.infradead.org/mailman/listinfo/hostap > > > > -- > Ben Greear <greearb@xxxxxxxxxxxxxxx> > Candela Technologies Inc http://www.candelatech.com _______________________________________________ Hostap mailing list Hostap@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/hostap
