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. > > 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). > > Thanks, > Ben > > > > > Dennis > > > >> > >> 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 > > > > > -- > Ben Greear <greearb@xxxxxxxxxxxxxxx> > Candela Technologies Inc http://www.candelatech.com > _______________________________________________ Hostap mailing list Hostap@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/hostap
