linux-wireless.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* Expected behavior with co-located 6GHz APs?
@ 2022-07-08 18:22 James Prestwood
  2022-07-12 18:29 ` James Prestwood
  0 siblings, 1 reply; 2+ messages in thread
From: James Prestwood @ 2022-07-08 18:22 UTC (permalink / raw)
  To: linux-wireless

Hi,

I am playing around with a 6ghz AP and noticed some behavior I didn't
expect.

The first issue I ran into was the regulatory domain. I'm in the US so
6GHz should be enabled but "iw reg get" initially doesn't show any 6GHz
frequencies. Its my understanding these frequencies get enabled by
received beacons, and indeed if I do a full passive scan the regulatory
domain gets updated, e.g.

iw wlan0 scan passive

After this, I can active scan and see my 6GHz AP. Which I'm assuming
was based on the RNR element since active scanning on 6GHz is
disallowed.

BUT, if the interface goes down, the regdom reverts back to country 00
requiring a full passive scan again to unlock 6GHz. This basically
prevents a supplicant from using 6GHz without doing a time intensive
passive scan.

I would make more sense that the regdom should be updated based on
finding an RNR element in addition to the beacon itself right?

Thanks,
James


^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: Expected behavior with co-located 6GHz APs?
  2022-07-08 18:22 Expected behavior with co-located 6GHz APs? James Prestwood
@ 2022-07-12 18:29 ` James Prestwood
  0 siblings, 0 replies; 2+ messages in thread
From: James Prestwood @ 2022-07-12 18:29 UTC (permalink / raw)
  To: linux-wireless

Update on this. I narrowed the issue down to the fact that its the
AX210 firmware which changes the regulatory domain, and this is not
being done for very limited scans on a few frequencies. There is
apparently some beacon/probe threshold to trigger a regdom change in
the firmware. Unclear exactly what this threshold is.

This poses a problem, at least for IWD, because we rely on scanning
just a few frequencies of our last known networks when starting up.
This allows us to connect very quickly. But now with this behavior we
are both unable to scan 6ghz from the start, and furthermore its not
guaranteed the regdom will get updated from this limited scan, (or even
a full scan for that matter) preventing 6ghz from being used.

I'm not too sure this can be worked around in userspace with any sort
of reliability. It seems like the FW needs to loosen the policy on
setting the regulatory domain for situations where a scan resulted in
only a few BSS's. In this case if all the beacons contain the same
country IE its a very high likelyhood that is the country. Otherwise,
if differing country IEs are found handle that however it does now.

Does this sound reasonable?

Thanks,
James

On Fri, 2022-07-08 at 11:22 -0700, James Prestwood wrote:
> Hi,
> 
> I am playing around with a 6ghz AP and noticed some behavior I didn't
> expect.
> 
> The first issue I ran into was the regulatory domain. I'm in the US
> so
> 6GHz should be enabled but "iw reg get" initially doesn't show any
> 6GHz
> frequencies. Its my understanding these frequencies get enabled by
> received beacons, and indeed if I do a full passive scan the
> regulatory
> domain gets updated, e.g.
> 
> iw wlan0 scan passive
> 
> After this, I can active scan and see my 6GHz AP. Which I'm assuming
> was based on the RNR element since active scanning on 6GHz is
> disallowed.
> 
> BUT, if the interface goes down, the regdom reverts back to country
> 00
> requiring a full passive scan again to unlock 6GHz. This basically
> prevents a supplicant from using 6GHz without doing a time intensive
> passive scan.
> 
> I would make more sense that the regdom should be updated based on
> finding an RNR element in addition to the beacon itself right?
> 
> Thanks,
> James
> 



^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2022-07-12 18:29 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-07-08 18:22 Expected behavior with co-located 6GHz APs? James Prestwood
2022-07-12 18:29 ` James Prestwood

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).