On 29-3-2017 9:46, Johannes Berg wrote:
>
>>>> 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...?
But this is prior to connection, right? This warning happens upon
authenticate. So in nl80211_authenticate() we do:
chan = nl80211_get_valid_chan(&rdev->wiphy,
info->attrs[NL80211_ATTR_WIPHY_FREQ]);
and in cfg80211_mlme_auth():
req.bss = cfg80211_get_bss(&rdev->wiphy, chan, bssid, ssid, ssid_len,
IEEE80211_BSS_TYPE_ESS,
IEEE80211_PRIVACY_ANY);
After that the chain is:
ieee80211_mgd_auth() ->
ieee80211_prep_connection() ->
ieee80211_prep_channel() ->
ieee80211_determine_chantype()
Regards,
Arend
