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: <4281590ec280540e52202e052a23cbba3a33a474.camel@sipsolutions.net>
Subject: Re: AP + STA on DFS channel breaks DFS detection.
From:   Johannes Berg <johannes@sipsolutions.net>
To:     Ben Greear <greearb@candelatech.com>,
        "linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>
Date:   Tue, 10 May 2022 16:31:09 +0200
In-Reply-To: <c937f0dc-5be7-8986-01a5-152c6b20e868@candelatech.com>
References: <c937f0dc-5be7-8986-01a5-152c6b20e868@candelatech.com>
Content-Type: text/plain; charset="UTF-8"
User-Agent: Evolution 3.42.4 (3.42.4-2.fc35) 
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Precedence: bulk

On Wed, 2022-04-27 at 14:32 -0700, Ben Greear wrote:
> I am using 5.17.4+ kernel, MT7915 radios.  One radio (wiphy0) is acting as AP on
> channel 132.  It starts, does CAC and starts working fine.
> 
> Then, I bring up a station on wiphy1 (on same machine).  The STA connects to the AP
> on wiphy0 and starts running traffic for a short time (usually < 1 minute).  And then
> the AP gets stopped.  I don't think this is specific to connecting AP to STA on same machine,
> probably if STA connected to another AP on channel 132 it would have same issue.
> 
> I think I have tracked this down by adding prints and WARN_ON to find
> the interesting state changes.  It looks like when the STA changes its
> regdom (probably because it is admin-up and/or associated to the AP), then the state of the
> channel's dfs_state is reset.  Channel objects are per band, not per wiphy.

Actually, they are per wiphy, unless the driver sets up something else?
I couldn't really figure out the code there, but it looked dynamically
allocated, so not sure...

> And then a bit later, a timer kicks off and decides that CAC has not completed
> (because it already completed earlier on the AP, but chan->dfs_state was lost,
> and STA will not do CAC anyway.)
> 
> So, question is, how in the world to fix this properly!
> 

Good question!

But I'm not sure your description of this is quite right - the point
isn't that the channels are shared, the point is that you're getting to
update_all_wiphy_regulatory() which does update _all_ of the devices,
since you've just switched the regulatory domain.

I guess if the rules are identical on a given channel before/after the
regdomain switch, we might get away with not resetting the dfs_state?

johannes