© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
f33e652
(Get the code!)
I'll take a shot at responding to @seb128's questions:
Why is this a rls issue in the LTS?
=======
Prior to jammy, the crda database was in userland, and the crda package provided a means (via editing /etc/default/crda) to persist the wireless region across reboots. From jammy onwards, the regulatory database is now baked into the kernel, and the crda package is gone (from Debian upstream and from Ubuntu). There is now no mechanism to set the wifi regulatory region that will persist across reboots on either server or desktop (iw reg set is transitory).
It appears (see comments 16 thru 19 above) that under *some* circumstances, with some APs that wpa-supplicant does correctly determine the wifi region, and sets it automatically (though the user has no way of knowing this other than digging through wpa-supplicant's logs). However, I'm not convinced this is terribly reliable -- it's apparently never worked for me at home or at various friends houses, and only once worked when I travelled to Germany for a sprint.
There is currently (in jammy onwards) one hacky way of ensuring the region is set on each reboot (from comment 12 above): set "cfg80211.
That covers the deficiency, which is new to jammy, but why is setting the regulatory region particularly important? In the 2.4GHz band [1], there's a "world" region which covers the vast majority of the available bands (1 thru 11). So for older wifi hardware, defaulting to the "world" region doesn't result in *much* limitation (though it does mean European users can't use bands 12 or 13, and Japanese users don't get their wonderfully separate band 14).
However, the 5GHz band [2] is a considerably different story. For starters, there's a great deal more variation in which channels are available in which regions. Moreover, certain channels have specific limitations in certain regions. Some require radar detection or mitigation mechanisms to ensure that 5GHz capable wifi devices don't interfere with certain radar applications [3]. Others require that certain channels are strictly for indoor use only. Leaving one's wifi device in the "world/unset" state for 5GHz typically results in a more limited experience than it does for 2.4GHz devices [4].
Then, of course, there's the legal aspect. I'm not qualified to comment on the relevant regulations around the globe but the section "Helping compliance by allowing to change regulatory domains" under [5] contains some interesting notes on the fact that wifi devices have both a "programmed" regulatory domain and a "selected" region (the latter is affected by crda) which can only *enhance* restrictions. That said, this is likely important from a legal perspective for those travelling with wifi capable equipment between countries with differing regulatory requirements.
[1]: https:/
[2]: https:/
[3]: https:/
[4]: https:/
[5]: https:/
What's the intended priority?
=======
Given this relates to legal requirements in many jurisdictions (again, I'm not qualified to comment on these specifically, but I don't think there's any argument that legal restrictions are at least present), would suggest this should be a reasonably high priority. The counter-point would be: it would appear there's been *never* been a graphical interface for setting this and (I presume?) no jurisdiction has ever complained about this.
However, the fact that the 5GHz experience (which is becoming more and more common) is, in certain jurisdictions, significantly affected by lacking this setting (because without setting the regulatory region, users in such regions can't access a large number of channels) would also suggest a reasonably high priority to me.
What's the impact?
==================
Hopefully covered in the prior sections.
What do we expect to be changed?
=======
At a bare minimum some mechanism for persisting a selected wifi regulatory domain is required, both on server images (via netplan) and desktop images (via network manager). During boot, some mechanism should restore the wifi regulatory domain from this persistent location.
There's some nuance here over whether an AP's broadcast region (if any) should take precedence over the persistent setting, and when exactly the restoration of the setting should occur (i.e. particularly in the server case, whether wifi should only be enabled strictly *after* restoration of this setting). There's probably more questions around this setting I'm not thinking of too. Suggestions welcome!
Beyond the bare minimum, some "nice to have" suggestions:
1. It would probably be useful for the desktop user to have some mechanism to see what wifi regulatory domain is currently in force (other than trawling log files). Arguably server users already have this via "iw". Desktop users could also install and use "iw", but personally I'd also like to see this info under the wifi settings (almost everything else related to wifi doesn't require command line interaction, so I don't see why this should be any different).
2. During ubiquity's initial setup, when location is selected for timezone, could wifi regulatory region also be implicitly set from this selection? Or should this be an explicitly separate setting? (or an option on the location selection; "do you want to set your wifi region to this location too?"). Obviously this suggestion isn't relevant to the server case, but the equivalent there would be some mechanism for netplan to provide a setting for first boot.
3. The timezone can automatically update based on geolocation; should the wifi region follow this? I don't think this is relevant for the server case (it's a reasonable assumption that servers don't regularly move and, if they are moved, that the server admin could adjust the configuration manually, presumably via netplan), but it seems a natural extension to the desktop case (given automatic timezone changing is already baked in).