> > > 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 }
>
> > 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
