[PATCH 1/2] tests: Active beacon req for primary/center channel

[Baligh GASMI]

Hello,

Any update on this ?

Thanks

Le jeu. 7 avr. 2022 à 23:58, Baligh GASMI <gasmibal at gmail.com> a écrit :
>
> Hi Jouni,
>
> To be honest, I had the same conclusion.
> It was clear for me that the Annex E does not contain such a
> combination, oper_class 128 and a channel number 36.
> But after executing some tests with other phones, this combination
> seems to be supported.
>
> The main question for us was which primary channel number to use when
> sending an RRM request, to cover the largest cases.
>
> You can find here some tests for 80MHz bandwidth (made by a very trusted team):
> RRM (opclass 128, ch 42) --> oppoA52 (home ch 40) --> no resp
> RRM (opclass 128, ch 40) --> oppoA52 (home ch 40) --> success
> RRM (opclass 128, ch 36) --> oppoA52 (home ch 40) --> empty resp
>
> RRM (opclass 128, ch 42) --> Redmi Note 7 (home ch 36) --> empty resp
> RRM (opclass 128, ch 36) --> Redmi Note 7 (home ch 36) --> success
> RRM (opclass 128, ch 40) --> Redmi Note 7 (home ch 36) --> empty resp
>
> RRM (opclass 128, ch 42) --> Vivo S1 Pro (home ch 36) --> no resp
> RRM (opclass 128, ch 36) --> Vivo S1 Pro (home ch 36) --> success
> RRM (opclass 128, ch 40) --> Vivo S1 Pro (home ch 36) --> empty resp
>
> RRM (opclass 128, ch 42) --> IPhone XR (home ch 36) --> no resp
> RRM (opclass 128, ch 36) --> IPhone XR (home ch 36) --> success
>
> RRM (opclass 128, ch 42) --> PC with wpa_supplicant v2.10 (home ch 36)
> --> success
> RRM (opclass 128, ch 36) --> PC with wpa_supplicant v2.10 (home ch 36)
> --> empty resp
> RRM (opclass 128, ch 40) --> PC with wpa_supplicant v2.10 (home ch 36)
> --> empty resp
>
> According to those tests it was clear for us that using the home
> primary channel was more reliable, and covered more cases !
>
> So, assuming that the RRM request is fine for most phones, I deduce
> that it is more suitable to add the support of these requests into
> wpa_supplicant.
> This is what patch 2/2 is about.
> What do you think ? Does this make sense ?
>
> Here you can find some logs from wpa_supplicant trying to find primary
> channels to scan (oper_class 128, RRM ch 48, home ch 48):
> wlan1: nl80211: scan request
> nl80211: Scan SSID Freebox-36C7D6
> nl80211: Scan frequency 5210 MHz
> nl80211: Scan frequency 5230 MHz
> nl80211: Scan frequency 5250 MHz
> nl80211: Scan frequency 5270 MHz
> nl80211: Add NL80211_SCAN_FLAG_FLUSH
> nl80211: Scan trigger failed: ret=-22 (Invalid argument)
> wlan1: CTRL-EVENT-SCAN-FAILED ret=-22
> wlan1: Radio work 'scan'@0xffffaaf8fdb0 done in 0.000908 seconds
> wlan1: radio_work_free('scan'@0xffffaaf8fdb0): num_active_works --> 0
> nl80211: Send Action frame (ifindex=9, freq=5240 MHz wait=0 ms no_cck=0)
> nl80211: CMD_FRAME freq=5240 wait=0 no_cck=0 no_ack=0 offchanok=1
>
> We can see that wpa_supplicant is accepting the request, but the found
> freqs are out of the current band !
> Maybe we must ignore such requests, I don't know ! But for me it's
> more appropriate to accept them.
>
> By the way, we tried to find other ways to workaround this.
> So we tried to use 225 as channel number with oper_class 128, and we
> added 'AP Channel Report' sub-element which contain another oper_class
> and list of channels, such:
> 80ff0000040001ffffffffffff33057324282c30
>
> With 33057324282c30 decoded as :
> [33] -> ID
> [05] -> len 5 bytes
> [73] -> OpClass 115
> [24282c30] -> Chan Num 36,40,44 and 48
>
> This seems to work in most cases (wpa_supplicant too), but we had a
> doubt about phones making offchannel scanning because of the
> oper_class change !
> What do you think about that ? Could this be a solution ?
>
> Thanks
>
>
> Le jeu. 7 avr. 2022 à 17:36, Jouni Malinen <j at w1.fi> a écrit :
> >
> > On Mon, Feb 28, 2022 at 09:55:23PM +0100, Baligh Gasmi wrote:
> > > Add tests for active beacon request to scan a specific VHT
> > > channel, either using primary channel or a center freq channel
> > > numbers.
> >
> > > diff --git a/tests/hwsim/test_rrm.py b/tests/hwsim/test_rrm.py
> > > +def test_rrm_beacon_req_active_scan_pri_channel(dev, apdev):
> > > +    """Beacon request - primary channel active scan mode - VHT80"""
> >
> > > +        token = run_req_beacon(hapd, addr, "80240000040001ffffffffffff")
> >
> > So this would indicate operating class 128 and channel number 36.
> > However, Annex E does not include such combination: the operating class
> > 128 does not specify a channel set; it defines only the channel center
> > frequency index values (42, 58, 106, 122, 138). Could you please
> > provide some more detail on why this should be considered to be a valid
> > request (and as such, why patch 2/2 would be needed to make this pass)?
> >
> > --
> > Jouni Malinen                                            PGP id EFC895FA