All of lore.kernel.org
 help / color / mirror / Atom feed
From: Johannes Berg <johannes@sipsolutions.net>
To: Ben Greear <greearb@candelatech.com>,
	"linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>
Subject: Re: AP + STA on DFS channel breaks DFS detection.
Date: Tue, 10 May 2022 16:31:09 +0200	[thread overview]
Message-ID: <4281590ec280540e52202e052a23cbba3a33a474.camel@sipsolutions.net> (raw)
In-Reply-To: <c937f0dc-5be7-8986-01a5-152c6b20e868@candelatech.com>

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

  parent reply	other threads:[~2022-05-10 15:03 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-27 21:32 AP + STA on DFS channel breaks DFS detection Ben Greear
2022-04-27 23:35 ` Ben Greear
2022-05-10 14:31 ` Johannes Berg [this message]
2022-05-10 19:17   ` Ben Greear

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4281590ec280540e52202e052a23cbba3a33a474.camel@sipsolutions.net \
    --to=johannes@sipsolutions.net \
    --cc=greearb@candelatech.com \
    --cc=linux-wireless@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.