Re: Test setup for .11k/v

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

 



On 3/19/19 10:37 AM, Jan.Fuchs@xxxxxxxxx wrote:
Dear Ben,

I've noticed your second mail too late ...
I'm actually doing similar stuff, with the difference I am using real access points instead of hostapd. ;)
11k/v is one of my testing topics in the near future, which is to be fully automated. I'm currently busy with fast-transition+wpa2/wpa3.
That's why I haven't thought about this too much, but my test setup would be: 2 APs with two wifi modules each, dual band.
One station e.g. wpa_supplicant or our own APs in station mode.

Thanks for these ideas.  When I previously automated 11r test cases, the basic algorithm was:

scan [freqs of APs]
sleep a few seconds to wait for scan to finish
initiate roam to some BSSID

You had to do the scan shortly before the roam attempt in order for the roam to happen properly because otherwise the bssid
is not found in the kernel or some such reason.

I'm thinking that with neigh-response, I should be able to request neigh report
and roam to one of those bssids instead of the 'scan freq and sleep' logic.

I am guessing that would be a real-world advantage of .11k over previous
roaming that needed off-channel scans.

That sound reasonable?

Thanks,
Ben


Just a quick shot on testcases:

11k testcases:
         - see the AssocReq, if the correct RM capabilites are set
         Link Measurement
         Neighbor Report:
       - if the station/ap supports (negative testcase) neighbor report (see assoc req)
       - expect 3 entries in neighbor list, with 2.4 GHz and 5 GHz Channels in response
      - store these 3 entries correctly (remark/my experience: most of the other stuff PHY Type and Operating Class is ignored or not really used from any comercial station)
       - roam to each entry successfully
         Beacon Passive Meaurements
         Beacon Active Measurements
         Beacon Table Measurements
         AP Channel Report
11v:
- Steering to a neighbor, with candidate list (same as in the neighbor report), no candidate (station shall decide on its own).
- Steering to a neighbor (in candidate list) which is not known to the station gets denied
- something about the Disaassoc Timer

Regards,
Jan



Von: Ben Greear <greearb@xxxxxxxxxxxxxxx>
An: Jan.Fuchs@xxxxxxxxx
Datum: 19.03.2019 18:09
Betreff: Re: Test setup for .11k/v
----------------------------------------------------------------------------------------------------------------------------------------------------------------



On 3/19/19 9:59 AM, Jan.Fuchs@xxxxxxxxx wrote:
 > Dear Ben,
 >
 > "AP responds with exactly one IE and it does not show the multiple neighbors that I expected to see."
 >
 > Never tried this with hostapd, but multiple neighbors in one neighbor report is possible.
 > See the tagged parameters in the second frame in the following pcap:

Thanks, as soon as I fixed the ssid printout, it works fine:

root@lf0313-6477 lanforge]# hostapd_cli -i vap0101 show_neighbor
04:f0:21:25:e0:b0 ssid=726f757465642d41502d313172 nr=04f02125e0b0af1900008028090603022a00 lci=[BLANK] civic=[BLANK] stationary=0
04:f0:21:f2:ea:b0 ssid=726f757465642d41502d313172 nr=04f021f2eab0af1900008028090603022a00 lci=[BLANK] civic=[BLANK] stationary=0
04:f0:21:2f:46:c3 ssid=726f757465642d41502d313172 nr=04f0212f46c3bf1900008064090603026a00 lci=[BLANK] civic=[BLANK] stationary=0
04:f0:21:71:39:c3 ssid=726f757465642d41502d313172 nr=04f0217139c3bf1900008064090603026a00 lci=[BLANK] civic=[BLANK] stationary=0
04:f0:21:c8:4e:c3 ssid=726f757465642d41502d313172 nr=04f021c84ec3bf1900008064090603026a00 lci=[BLANK] civic=[BLANK] stationary=0
04:f0:21:a3:6e:c3 ssid=726f757465642d41502d313172 nr=04f021a36ec3bf1900008064090603026a00 lci=[BLANK] civic=[BLANK] stationary=0
04:f0:21:9d:47:c3 ssid=726f757465642d41502d313172 nr=04f0219d47c3bf1900008064090603026a00 lci=[BLANK] civic=[BLANK] stationary=0

And from the hostad_cli monitor:

2019-03-19 10:00:25.539  1.1:  IFNAME=sta0000 <3>RRM-NEIGHBOR-REP-RECEIVED bssid=04:f0:21:9d:47:c3 info=0x19bf op_class=128 chan=100 phy_type=9
2019-03-19 10:00:25.539  1.1:  IFNAME=sta0000 <3>RRM-NEIGHBOR-REP-RECEIVED bssid=04:f0:21:a3:6e:c3 info=0x19bf op_class=128 chan=100 phy_type=9
2019-03-19 10:00:25.539  1.1:  IFNAME=sta0000 <3>RRM-NEIGHBOR-REP-RECEIVED bssid=04:f0:21:2f:46:c3 info=0x19bf op_class=128 chan=100 phy_type=9
2019-03-19 10:00:25.539  1.1:  IFNAME=sta0000 <3>RRM-NEIGHBOR-REP-RECEIVED bssid=04:f0:21:71:39:c3 info=0x19bf op_class=128 chan=100 phy_type=9
2019-03-19 10:00:25.539  1.1:  IFNAME=sta0000 <3>RRM-NEIGHBOR-REP-RECEIVED bssid=04:f0:21:c8:4e:c3 info=0x19bf op_class=128 chan=100 phy_type=9
2019-03-19 10:00:25.539  1.1:  IFNAME=sta0000 <3>RRM-NEIGHBOR-REP-RECEIVED bssid=04:f0:21:f2:ea:b0 info=0x19af op_class=128 chan=40 phy_type=9
2019-03-19 10:00:25.539  1.1:  IFNAME=sta0000 <3>RRM-NEIGHBOR-REP-RECEIVED bssid=04:f0:21:25:e0:b0 info=0x19af op_class=128 chan=40 phy_type=9

In case you have any ideas....if you were trying to test out k/v, what sort of test cases would you want
to see?

Thanks,
Ben

 >
 >
 > Regards, Jan
 >
 >
 >
 >
 > ----------------------------------------------------------------------------------------------------------------------------------------------------------------
 >
 >
 >
 > LANCOM Systems GmbH
 > Adenauerstr. 20 / B2
 > 52146 Würselen
 > Deutschland
 >
 > Tel: +49 2405 49936-0
 > Fax: +49 2405 49936-99
 >
 > Web: https://www.lancom-systems.de <https://www.lancom-systems.de/>
 >
 >
 >
 > Geschäftsführer: Ralf Koenzen, Stefan Herrlich
 > Sitz der Gesellschaft: Aachen, Amtsgericht Aachen, HRB 16976
 > ----------------------------------------------------------------------------------------------------------------------------------------------------------------
 >
 >
 >
 >
 >
 >
 > Von: Ben Greear <greearb@xxxxxxxxxxxxxxx>
 > An: Jouni Malinen <j@xxxxx>
 > Kopie: Dennis Bland <dennis@xxxxxxxxxxxxxxxxx>, hostap@xxxxxxxxxxxxxxxxxxx
 > Datum: 19.03.2019 17:40
 > Betreff: Re: Test setup for .11k/v
 > Gesendet von: "Hostap" <hostap-bounces@xxxxxxxxxxxxxxxxxxx>
 > ----------------------------------------------------------------------------------------------------------------------------------------------------------------
 >
 >
 >
 > On 3/14/19 4:09 PM, Ben Greear wrote:
 >  > On 3/14/19 4:00 PM, Jouni Malinen wrote:
 >  >> On Thu, Mar 14, 2019 at 01:03:11PM -0700, Ben Greear wrote:
 >  >>> On 3/14/19 12:42 PM, Dennis Bland wrote:
 >  >>>> 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?
 >  >>
 >  >> That sounds pretty ugly.. If this really needs to come from the
 >  >> configuration file, I think I'd rather go with a new config parameter
 >  >> being added with a format that I guess would be quite similar to the
 >  >> SET_NEIGHBOR control interface command and the parser would also be very
 >  >> similar to hostapd_ctrl_iface_set_neighbor().
 >  >>
 >  >> That said, I don't see why you would do this over the control
 >  >> interface.. Normal use cases will need to update this information more
 >  >> dynamically anyway, so the control interface is needed and whatever is
 >  >> reloading/restarting an interface could as well run through number of
 >  >> hostapd_cli calls or direct interaction with the control interface.
 >  >
 >  > Ok, I got worried trying to load it at boot time would be problematic for
 >  > other reasons as well.
 >  >
 >  > At least for the casual user, building the neighbor report IE to be passed
 >  > into the CLI seems a bit tricky.  (And according to google, exactly no one has
 >  > ever posted a working example of that command :))
 >  >
 >  > Is there any way to query a hostapd using hostapd_cli or similar to get
 >  > a dump of what it thinks is its own neigh report? Then, I could query
 >  > all of the hostapd in question, and just pipe the output into the other hostapd
 >  > neigh table through hostapd_cli without having to fully parse/build the IE?
 >
 > So, I went ahead and built the way to show current neigh db, per previous patches,
 > and I rigged up my software to add neighbor entries to a group of APs.
 >
 > # hostapd_cli -i vap0001 show_neighbor
 > 04:f0:21:2f:46:c3 ssid=04f0212f46c3bf190000806409 nr=04f0212f46c3bf1900008064090603026a00 lci=[BLANK] civic=[BLANK] stationary=0
 > 04:f0:21:71:39:c3 ssid=04f0217139c3bf190000806409 nr=04f0217139c3bf1900008064090603026a00 lci=[BLANK] civic=[BLANK] stationary=0
 > 04:f0:21:c8:4e:c3 ssid=04f021c84ec3bf190000806409 nr=04f021c84ec3bf1900008064090603026a00 lci=[BLANK] civic=[BLANK] stationary=0
 > 04:f0:21:9d:47:c3 ssid=04f0219d47c3bf190000806409 nr=04f0219d47c3bf1900008064090603026a00 lci=[BLANK] civic=[BLANK] stationary=0
 > 04:f0:21:a3:6e:c3 ssid=04f021a36ec3bf190000806409 nr=04f021a36ec3bf1900008064090603026a00 lci=[BLANK] civic=[BLANK] stationary=0
 > 04:f0:21:f2:ea:b0 ssid=04f021f2eab0af190000802809 nr=04f021f2eab0af1900008028090603022a00 lci=[BLANK] civic=[BLANK] stationary=0
 > 04:f0:21:25:e0:b0 ssid=04f02125e0b0af190000802809 nr=04f02125e0b0af1900008028090603022a00 lci=[BLANK] civic=[BLANK] stationary=0
 >
 > I associated a station to this neigh show above, and requested a neighbor report:
 >
 > ./local/bin/wpa_cli -i sta0000 neighbor_rep_request
 >
 >
 > I see the action frame go to AP, and I see AP respond, but AP responds with exactly one IE
 > and it does not show the multiple neighbors that I expected to see.
 >
 > So, *should* I see info about multiple neighbors returned?  Am I using this wrong?
 >
 > Thanks,
 > Ben
 >
 >  >
 >  > Thanks,
 >  > Ben
 >  >
 >  >
 >
 >
 > --
 > Ben Greear <greearb@xxxxxxxxxxxxxxx>
 > Candela Technologies Inc _http://www.candelatech.com_ <http://www.candelatech.com/>
 >
 >
 > _______________________________________________
 > Hostap mailing list
 > Hostap@xxxxxxxxxxxxxxxxxxx
 > _http://lists.infradead.org/mailman/listinfo/hostap_
 >
 > /(See attached file: iphone7-neighborreport.pcapng)/


--
Ben Greear <greearb@xxxxxxxxxxxxxxx>
Candela Technologies Inc http://www.candelatech.com <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