Received-SPF: pass (google.com: domain of linux-wireless-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <1c1a0a2c454dafcfaa19995974448ee5836fd9f7.camel@gmail.com>
Subject: Expected behavior with co-located 6GHz APs?
From:   James Prestwood <prestwoj@gmail.com>
To:     "linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>
Date:   Fri, 08 Jul 2022 11:22:04 -0700
Content-Type: text/plain; charset="UTF-8"
User-Agent: Evolution 3.40.4 (3.40.4-3.fc34) 
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Precedence: bulk

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