quoted

quoted

19:23:29 kernel: wlan0: authenticate with 00:11:22:33:44:55
19:23:29 kernel: ------------[ cut here ]------------
19:23:29 kernel: WARNING: CPU: 0 PID: 18925 at
net/mac80211/mlme.c:287 ieee80211_determine_chantype+0x12e/0x380

284	while (!cfg80211_chandef_usable(sdata->local->hw.wiphy,
chandef,
285					tracking ? 0 :
286					   IEEE80211_CHAN_DISABLED
)) {
287		if (WARN_ON(chandef->width ==
NL80211_CHAN_WIDTH_20_NOHT)) {
288			ret = IEEE80211_STA_DISABLE_HT |
289			      IEEE80211_STA_DISABLE_VHT;
290			break;
291		}

quoted

This is already indicating a severe problem. I don't know how you
end
up in this situation with b43, since that doesn't have any
regulatory
magic afaict.

The only way this WARN_ON can kick in is below so may be interesting
to log the three variables checked in 'if' statement.

Yeah we should probably extend the WARN_ON() to a WARN() with that
information.

Could it be a radar channel and it's waiting for CAC timeout or
whatever the term is ;-) ?

No. Not even tongue-in-cheek :-)
This code was designed for regulatory changes, but the WARN_ON()
indicates that we got connected on a channel that we think isn't
actually usable. We quite possibly should reject that connection there,
but it seems to me it should've been rejected elsewhere already...?

johannes