Re: Test setup for .11k/v

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 3/14/19 12:42 PM, Dennis Bland wrote:
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).

I want to test our controlled stations against third-party APs, as well
as allow testing third-party stations against our APs, so purposefully
triggering neigh report requests on our station is fine for our purposes.

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.

I'd like to configure this in the .conf file so that I don't have to reload it
on vap restart, etc.

Currently, I don't see a way to do that.  Anyone have opinions on adding
a 'cli' command to the config-file logic that would just pipe the rest of
the line into the hostapd_cli logic on startup?

Thanks,
Ben


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



--
Ben Greear <greearb@xxxxxxxxxxxxxxx>
Candela Technologies Inc  http://www.candelatech.com


_______________________________________________
Hostap mailing list
Hostap@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/hostap



[Index of Archives]     [Linux Wireless]     [Linux Kernel]     [ATH6KL]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Samba]     [Device Mapper]

  Powered by Linux