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
