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@xxxxx> 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
_______________________________________________
Hostap mailing list
Hostap@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/hostap
