On 3/21/19 7:52 PM, Dennis Bland wrote:
On Thu, Mar 21, 2019 at 1:03 PM Ben Greear <greearb@xxxxxxxxxxxxxxx> wrote:
On 3/21/19 11:50 AM, Dennis Bland wrote:
Hi Ben:
On Thu, Mar 21, 2019 at 12:00 PM Ben Greear <greearb@xxxxxxxxxxxxxxx> wrote:
On 3/13/19 6: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.
Hello,
I started working on the beacon report request. It appears that APs
cannot send to a station that is not connected to it. So, in that case,
the controller cannod do what you suggest above.
Is this a limitation in hostapd or did I mis-understand what you are suggesting?
I *am* able to send beacon requests to a STA from the AP (hostapd) to which it
is connected.
Yes, you are correct - sorry for being unclear. The AP can only send
beacon report requests to a currently connected STA. In my original
comment, I was thinking of a scenario with multiple APs and one or
more STAs connected to each AP. The AP controller would receive a
beacon report from each STA and determine if TPC or an 802.11v TM is
recommended for a particular STA.
It would be cool if you do request a beacon from any STA out there, but otherwise
it would seem you'd need to sniff on the AP(s) or something like that to know RSSI
of non-attached peers?
APs will typically perform background scans during periods of low
activity (to reduce performance impact) in order to update AP neighbor
lists, but this scan often gets deferred in busy or congested APs.
Theoretically, a STA connected to an AP that receives a beacon report
request could send an 802.11u GAS public action frame to nearby STAs
to request their beacon report(s), but that would be a proprietary
implementation.
If you mean a background sniff, then maybe that would work, but an AP scan
is not going to find stations.
I wonder if you could at least get an ACK out of a station if you faked
the source-address to match the BSSID of the AP to which it is currently
connected.
Then, the other APs in the area could spin up a virtual AP/BSSID, send
a 'fake' nullfunc frame to the STA, and then quickly bring back down
the virtual AP. This virtual AP would need to be set to not ack any
frames so it would not conflict with the real AP.
If you get an ACK from the nullfunc, you can use that
to determine RSSI. Maybe a sniff would be simpler and easier though.
On to the next thing now...I saw there is a command to request LCI from a station,
but when I try that, hostapd says the station doesn't support LCI.
Any idea how to get that working?
Is LCI enabled in your STA RM Capabilities IE for (re)association
requests? Your STA WLAN driver may not support active LCI (e.g.
time-of-arrival measurement), but for testing purposes a static
location should be possible.
And perhaps more important, what is LCI for? I found an example IE hex in the
test_rrm.py logic, but haven't found how it decodes yet, and found too much about
LCI in the ieee spec to know easily where to begin...
LCI can be used for emergency services to locate the STA, or for asset
tracking management systems in an indoor environment where GNSS isn't
available or reliable (e.g. multi-story hospitals).
Ahh, OK. I guess that my ath10k driver probably doesn't support that
at least for now.
What about the CIVIC field....do you know what it is used for?
Thanks,
Ben
--
Ben Greear <greearb@xxxxxxxxxxxxxxx>
Candela Technologies Inc http://www.candelatech.com
_______________________________________________
Hostap mailing list
Hostap@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/hostap
