On 5/10/22 7:31 AM, Johannes Berg wrote:
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.
It is a tangled mess of code, but if I understand it properly, the channel objects
*are* shared between wiphy devices, and...not sure it really matters either way,
since logically the regdom stuff is combined and then the values that are actually
used are the subset that is supported by all regdom configuration? Maybe there
are special cases to that for things like iwlwifi that does its own regdom
stuff too...but I was only using mtk radios int his particular test case.
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?
Yes, and it seems very painful to properly make that determination the way
the regdom code is currently implemented: I could not see a clean way to grab
a 'before' and 'after' snapshot to compare against. During the regdom rebuild process,
the regdom changes with each new regdom input applied, so you cannot really check
incremental changes to detect a change in the end result.
Thanks,
Ben
johannes
--
Ben Greear <greearb@xxxxxxxxxxxxxxx>
Candela Technologies Inc http://www.candelatech.com
