Right, during boot we have brcmf_cfg80211_attach, which does the
following in order:
- brcmf_setup_wiphy- setup the wiphy struct and fill in the the
frequencies of the bands and the channels
- wiphy_apply_custom_regulatory- interesting, it applies a world
regulatory setting. Which looks like this:
/* This is to override regulatory domains defined in cfg80211 module (reg.c)
* By default world regulatory domain defined in reg.c puts the flags
* NL80211_RRF_NO_IR for 5GHz channels (for * 36..48 and 149..165).
* With respect to these flags, wpa_supplicant doesn't * start p2p
* operations on 5GHz channels. All the changes in world regulatory
* domain are to be done here.
*/
static const struct ieee80211_regdomain brcmf_regdom = {
.n_reg_rules = 4,
.alpha2 = "99",
.reg_rules = {
/* IEEE 802.11b/g, channels 1..11 */
REG_RULE(2412-10, 2472+10, 40, 6, 20, 0),
/* If any */
/* IEEE 802.11 channel 14 - Only JP enables
* this and for 802.11b only
*/
REG_RULE(2484-10, 2484+10, 20, 6, 20, 0),
/* IEEE 802.11a, channel 36..64 */
REG_RULE(5150-10, 5350+10, 160, 6, 20, 0),
/* IEEE 802.11a, channel 100..165 */
REG_RULE(5470-10, 5850+10, 160, 6, 20, 0), }
};
- brcmf_setup_wiphybands: this is the part where the flags are changed
according to the applied regulatory settings (all channels are allowed
before this, but after this finishes we have some channels marked
invalid)
No actual connection attempt is made till now, only the wiphy struct is is
created.
When we try to connect for the first time (netplan apply), we get dump_survey,
then we get the regulatory resetting from the WiFi AP packets.
But if we do netplay apply again, restore_custom_reg_settings kicks in, which
does flags = orig_flags, so any regulatory setting is wiped off
The world regulatory setting is not reapplied, and the reconnect cycle goes on
again. This calls dump_survey first, as the driver is under the assumption that
some regulatory setting has already been applied, and it fails for the invalid
channels. After connecting, we get the regulatory resetting from the WiFi AP
packets, and everything works fine.
The potential fix can be setting the world regdom using
wiphy_apply_custom_regulatory and brcmf_setup_wiphybands again after
every disconnect. This gives a default regdom before trying to connect
to avoid the problematic channels, which can be enabled automatically
after the connection is established by the WiFi AP packets
We can also change the orig_flags of each channel during
brcmf_setup_wiphybands, but that doesn’t feel right to me.
Ofc, we are going to move the default regulatory logic from
brcmf_cfg80211_attach to the function which initiates a connection. I am not
sure which of these 2 approaches are better, but this is obviously better than
the suggestion given upstream to just disable DUMP_OBSS
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2063365
Title:
brcmfmac: brcmf_set_channel: set chanspec 0x100c fail, reason -52
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux-raspi/+bug/2063365/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
