While not resolved, I have got much closer on this.
In net/wireless/reg.c, around line 2000:
disable_chan:
/* We will disable all channels that do not match our
* received regulatory rule unless the hint is coming
* from a Country IE and the Country IE had no information
* about a band. The IEEE 802.11 spec allows for an AP
* to send only a subset of the regulatory rules allowed,
* so an AP in the US that only supports 2.4 GHz may only send
* a country IE with information for the 2.4 GHz band
* while 5 GHz is still supported.
*/
if (initiator == NL80211_REGDOM_SET_BY_COUNTRY_IE &&
PTR_ERR(rrule) == -ERANGE)
return;
if (lr->initiator == NL80211_REGDOM_SET_BY_DRIVER &&
request_wiphy && request_wiphy == wiphy &&
request_wiphy->regulatory_flags & REGULATORY_STRICT_REG) {
pr_debug("Disabling freq %d.%03d MHz for good\n",
chan->center_freq, chan->freq_offset);
chan->orig_flags |= IEEE80211_CHAN_DISABLED;
chan->flags = chan->orig_flags;
} else {
pr_debug("Disabling freq %d.%03d MHz\n",
chan->center_freq, chan->freq_offset);
chan->flags |= IEEE80211_CHAN_DISABLED;
}
return;
You can see that the orig_flags are only updated when the REGDOM is set by the
driver and strict regulatory option is chosen.
Before this step, a channel is never marked disabled.
Now, when we reapply the netplan config, we trigger restore_regulatory_settings
in net/wireless/reg.c, which in turn calls restore_custom_reg_settings, which
has the following:
for (band = 0; band < NUM_NL80211_BANDS; band++) {
sband = wiphy->bands[band];
if (!sband)
continue;
for (i = 0; i < sband->n_channels; i++) {
chan = &sband->channels[i];
chan->flags = chan->orig_flags;
chan->max_antenna_gain = chan->orig_mag;
chan->max_power = chan->orig_mpwr;
chan->beacon_found = false;
}
}
Restore the flags with orig_flags.
Then I presume the whole brcmfmac detach and attach happens.
For some reason, the dump_obss step runs before setting the regdom when we
reapply the config, and that leads to this log spam.
We can now focus on 2 things - why are we not updating the orig_flags in
handle_channel, and how can we change the order of execution of regdom
setting and dump_obss step.
Regdom setting takes place in multiple ways:
enum nl80211_reg_initiator {
NL80211_REGDOM_SET_BY_CORE,
NL80211_REGDOM_SET_BY_USER,
NL80211_REGDOM_SET_BY_DRIVER,
NL80211_REGDOM_SET_BY_COUNTRY_IE,
};
I am assuming that during boot, we use a regdom specified by the driver
or by the core, which doesn’t get carried on during the
restore_regulatory_settings call. When we reapply the config, it uses
all the channels, and then sets the regdom when it gets a country_ie
packet from the AP? anyways I must test this hypothesis as well. (during
boot it does get set by the driver, during the 2 runs I had)
** Changed in: linux-raspi (Ubuntu)
Milestone: ubuntu-25.04-beta => None
--
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
