Need option to specify wifi regulatory domain #3926
Comments
|
Launchpad user James Falcon(falcojr) wrote on 2021-12-01T16:25:16.135587+00:00 Since cloud-init's network v2 support is just straight pass-through to netplan, there doesn't seem to be anything for cloud-init to do here. I'm marking this invalid for cloud-init, but feel free to change the status back to new if I'm missing something. |
|
Launchpad user Lukas Märdian(slyon) wrote on 2021-12-16T10:05:26.420861+00:00 I am not sure if netplan (i.e. the network definition of a specific WiFi interface) is the correct place to handle this. The regulatory domain is a global concept that is being handled in the kernel and affects all radio devices, like WiFi and Bluetooth. If we change that on a single wifi interface definition, it will have side-effects on other radios. crda is being used for that global setting and it can be configured in /etc/default/crda, e.g.: $ cat /etc/default/crda Then there are drivers (like iwlwifi), that do it on their own way or do "Location Aware Regulatory" (LAR) and ignore any hints the kernel might pass to them. What's the output of Having a configuration setting in netplan, we could certainly instruct wpa_supplicant to pass a |
|
Launchpad user Floris(bos) wrote on 2021-12-16T10:40:00.079780+00:00
I tagged cloud-init just in case, as I was already expecting it to turn it into a discussion whether this belongs in Netplan, or is more a global localization like setting. Using a post-install script to patch /etc/default/crda is problematic, because post-install scripts are executed so late. ===
Are you sure it is the kernel that is treating this as a global thing, and not just your implementation? Other distributions (like RPI OS) set the country in wpa_supplicant.conf instead of your /etc/default/crda, and think you can have a different wpa_supplicant.conf per adapter. BTW on the Ubuntu 21.10 aarch64 Pi image it always seems to show as UNSET even if I do set /etc/default/crda and reboot, which may be another bug. == Set REGDOMAIN to a ISO/IEC 3166-1 alpha2 country code so that iw(8) may setthe initial regulatory domain setting for IEEE 802.11 devices which operateon this system.Governments assert the right to regulate usage of radio spectrum withintheir respective territories so make sure you select a ISO/IEC 3166-1 alpha2country code suitable for your location or you may infringe on locallegislature. See `/usr/share/zoneinfo/zone.tab' for a table of timezonedescriptions containing ISO/IEC 3166-1 alpha2 country codes.REGDOMAIN=GB phy#0 == |
|
Launchpad user Dave Jones(waveform) wrote on 2021-12-16T12:46:51.440183+00:00
Even if it is a global setting (as floris has pointed out, iw reg lists it per phy), surely that's the common use-case? If someone really needs different regions for different radio devices (on one system!) then we could declare that "too complex, out of scope" and leave it to them to configure externally to netplan.
That's odd -- I've just tried the same on a jammy development install and it's persisting happily across reboots. I'll flash a fresh impish image and see if I can replicate (I'll file a separate bug if I can). |
|
Launchpad user Lukas Märdian(slyon) wrote on 2021-12-16T16:30:14.974307+00:00 If we make this a (potentially global?) netplan setting, we'd want to also update /etc/default/crda on 'netplan generate' probably. |
|
Launchpad user Jerry Vonau(jvonau) wrote on 2021-12-22T11:00:47.139572+00:00 https://bugs.launchpad.net/ubuntu/+source/linux-firmware/+bug/1862760 |
|
Launchpad user Dave Jones(waveform) wrote on 2022-01-24T21:00:45.241949+00:00 Worth noting that crda is now "obsolete" and has been replaced with wireless-regdb (LP: #1958918), read directly by the kernel. I need to dig into how this is configured instead (if the existing "iw" command is no longer valid, quite a bit of documentation will need changing!) |
|
Launchpad user Jerry Vonau(jvonau) wrote on 2022-01-24T21:43:47.319639+00:00 My understanding is that only wpa_supplicant and iw are able to set the regdb country code. |
|
Launchpad user Floris(bos) wrote on 2022-01-24T22:08:28.878543+00:00
"iw" itself is not in the crda package. So perhaps just let netplan set country code in wpa_supplicant.conf and don't bother with /etc/default/crda ?! |
|
Launchpad user Jerry Vonau(jvonau) wrote on 2022-01-24T22:14:56.215552+00:00 While I have your ear can I suggest adding rng-tools, fake-hwclock, and haveged to the RPi images please. |
|
Launchpad user Dave Jones(waveform) wrote on 2022-01-24T22:30:36.287321+00:00 A quick response to jvonau above (to avoid getting side-tracked): the best place to suggest that would be to file a ticket against one of those packages and tag it "raspi-image" (which should bring it to my attention); I can add the other packages as "also affected". However, from a brief look, none of those packages are in "main" and therefore can't be added to official images without going through the full MIR process (which would need a pretty strong justification -- which is not to say there isn't one, just to make you aware of the requirement). |
|
Launchpad user Dave Jones(waveform) wrote on 2022-01-26T15:45:08.709977+00:00 On the subject of crda being deprecated, the situation appears to be as follows:
For example, on the Pi, in lieu of any other solution, I'll likely be recommending that people add "cfg80211.ieee80211_regdom=GB" (or the appropriate country code) to "/boot/firmware/cmdline.txt". The assumption from the kernel side seems to be that persisting this is "something for the desktop to handle", which seems pretty sensible given that one of the queries in almost any desktop setup (including ours) is "where are you?" from which we derive the timezone but could equally derive the regulatory region (I note we don't currently appear to -- perhaps this bug should affect ubiquity too?). Obviously, however, that doesn't deal with things like the server images. Personally, I think this only bolsters the case for adding the configuration to netplan or cloud-init. Unless we want to add a separate mechanism for persisting the regulatory domain, and then have to ensure that it is set sufficiently early that whatever wifi configuration is performed by netplan/cloud-init is done with the correct regulatory domain in force? |
|
Launchpad user Launchpad Janitor(janitor) wrote on 2022-01-26T16:17:11.864166+00:00 Status changed to 'Confirmed' because the bug affects multiple users. |
|
Launchpad user Jerry Vonau(jvonau) wrote on 2022-01-27T07:41:26.888020+00:00 This rings a bell, working from memory with wireshark I think NetworkManager does a double connect, first to grab the country code then the actual wpa_supplicant/dhcp exchange. Dan Williams would be the one to ask. |
|
Launchpad user Dave Jones(waveform) wrote on 2022-05-06T09:38:23.788839+00:00 @jvonau I just came back to this while trawling through my still-open bug list and had a look at what happens on the desktop. At least on our Pi desktop images (using NetworkManager), no wifi regulatory domain gets set at all (at least on my local network). Just in case it made any difference, I also tried switching on "location services", but there was no effect on the regulatory domain. It appears that the effort to make NetworkManager (or more broadly, the GNOME desktop) location aware stalled some considerable time ago 1 2 3 Also, I don't see any option to manually set the regulatory domain in the UI. Now that crda's gone in jammy, and "iw" isn't seeded on the desktop image (for the Pi at least; is the PC any different?) there's effectively no way for the user to set the wifi regulatory domain (something that's fairly important ... legal stuff and all that) "out of the box" either via the GUI or via the command line. I've added the info the jammy release notes, and I'm going to add a few targets here as this clearly needs some work on several fronts, presumably netplan for servers and NetworkManager for desktops. |
|
Launchpad user Jerry Vonau(jvonau) wrote on 2022-05-06T15:01:12.755073+00:00 Connection via NetworkManager to AP 2993 May 6 09:55:54 124-u2204-desk NetworkManager[641]: [1651845354.5017] device (wlp2s0): Activation: starting connection '181-rpi4-64bit-raspios-LARGE' (9a51eba2-3723-4750-8a72-aa2e4c723140) Disconnection from AP 3098 May 6 09:58:44 124-u2204-desk kernel: [ 856.512766] wlp2s0: deauthenticating from 02:72:82:96:ac:1e by local choice (Reason: 3=DEAUTH_LEAVING) Note: CTRL-EVENT-REGDOM-CHANGE changes as the connection is toggled on and off. Think everything is fine on that front. I think all the variables for wpa_supplicant.conf are passed across dbus from NetworkManager, I can't seem to find any temporary file within /run/ that has any mention of the wifi connection. Think the easiest path would be for netplan's systemd-network backend to populate wpa_supplicant.conf with a country_code entry from within the 'wifis' section of the yamal file, that would be the equivalent to how RaspOS handles setting up it's wpa_supplicant.conf file. |
|
Launchpad user Dave Jones(waveform) wrote on 2022-05-09T10:38:26.456537+00:00 I'm not entirely convinced NetworkManager is working correctly this regard? I was checking the wifi regulatory domain with "iw reg get" which consistently shows UNSET both globally and for phy#0 under the desktop for Pi images: $ iw reg get phy#0 Still, perhaps "iw" doesn't know about changes that wpa_supplicant makes? On a freshly flashed jammy pi desktop card, I get the following output when looking for REGDOM in the wpa_supplicant logs: $ journalctl -u wpa_supplicant -g REGDOM The "WORLD" region is presumably consistent with "UNSET" so it doesn't look like NetworkManager or wpa_supplicant is setting things correctly there. I wondered if perhaps it this only works on some APs? So here's the output from my regular development Pi. This also runs the jammy desktop, but it's not a freshly flashed image -- it's been upgraded thru every release since hirsute so it's probably a bit crufty -- but it has travelled with me to various places so it's seen a few different access points (it spends most of its time on ethernet at home though, so the lack of lots of REGDOM changes is not too surprising): -- Boot 3342ed4b84f14e6a8f7b900d240b2c4d -- So the upgraded image never sets "GB" either, but it did correctly figure out I'd dragged it into Germany (DE) for the engineering sprint in late February! Still, after that it was back to "WORLD" back in blighty. Am I looking in the wrong place for REGDOM events? Is there another wpa_supplicant instance that's setting things correctly? Or perhaps there's some setting I'm missing? (although that sounds unlikely given it did correctly figure out Germany). |
|
Launchpad user Jerry Vonau(jvonau) wrote on 2022-05-09T14:13:11.007284+00:00
That is the impression that I get, the country code info is part of the management frames transmitted by the AP, could be unsupported, not configured, or mis-configured. grep wpa may6.txt Should be part of the 'beacon' info. https://howiwifi.com/2020/07/13/802-11-frame-types-and-formats/ has a good overview. I discovered this exchange while observing 'on the wire' with wireshark.
It's the right place but wpa_supplicant has to interact with a variety wifi chipsets with varying firmware/drivers in play, would not surprise me if things are not consistent across the board. There also the difference between NetworkManger 'user connections'/'system connections' but that should not matter as NM passes the wifi info to wpa_supplicant directly. |
|
Launchpad user Dave Jones(waveform) wrote on 2022-05-09T21:34:41.726084+00:00
Thanks for the link; lots of useful stuff there!
Okay, to my mind that brings us back to "need option to specify wifi regulatory domain". It seems the situation with netplan/networkd is "there's no option", and in NetworkManager is "there's no option, but sometimes it'll magically work anyway" (although you'll need to go digging in the logs to confirm that :) |
|
Launchpad user Sebastien Bacher(seb128) wrote on 2022-05-31T14:19:42.223743+00:00 The issue has been nominated for network-manager on jammy which put it on the desktop rls list but it's unclear for us why that is consider a rls issue in the LTS and what's the intended priority? Could you provide a bit more explanation of the impact and what do you expect to be changed? |
|
Launchpad user Dave Jones(waveform) wrote on 2022-05-31T16:55:55.452481+00:00 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.ieee80211_regdom" on the kernel command line. Obviously this isn't terribly user friendly! 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. 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:
|
|
Launchpad user Sebastien Bacher(seb128) wrote on 2022-05-31T18:32:25.983093+00:00 Thanks for the details Dave, there is also a feature request upstream for network manager on https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/960 |
|
Launchpad user Sebastien Bacher(seb128) wrote on 2022-05-31T18:51:36.631305+00:00 extra questions, when you wrote
is that having a visible impact for users? like was your computer not able to connect to some access point? if that's the consequence of the issue it is a bit surprising that we got no user report of the type of 'my laptop isn't able to connect to my AP anymore since the upgrade to the new LTS' no? or is the issue somehow specific to raspi devices? |
|
Launchpad user Sebastien Bacher(seb128) wrote on 2022-05-31T19:24:34.835518+00:00 upstream replied ''' crda binaries were deprecated, but because there is an alternative mechanism (wireless-regdb?), isn't it? It could be maybe added to NetworkManager, if somebody sends a patch. But it's not actually clear to me that this is really NetworkManager's task. Maybe it is, but what are the arguments for that? |
|
Launchpad user Dave Jones(waveform) wrote on 2022-06-01T10:38:14.122225+00:00
Personally, I've never encountered issues with WiFi on a Pi. However, Notably, this also means I don't use bonded 5GHz channels in my home
The complaint usually isn't "I can't connect to my AP anymore". It's Mostly though, this comes up on IRC, and it's a safe bet that the One other (anecdotal) observation is that despite RaspiOS having a Given 5GHz setups are only likely to become more common in future |
|
Launchpad user Dave Jones(waveform) wrote on 2022-06-01T11:31:16.102378+00:00
I could be glib, and say "because the kernel says so 1". However, I A more complete argument would be: it appears that, where possible, All the underlying pieces are in place for the user to do so. Nothing Command line users already have the tools to do this (iw), although Why NetworkManager? This setting could arguably go under "Language and Region". It is But consider the debugging scenario: I've travelled from the UK to To me at least, it does seem to make sense for this to go under the |
|
Launchpad user Sebastien Bacher(seb128) wrote on 2022-06-01T11:43:51.281720+00:00 @dave, do you want to maybe add your input directly to the upstream report? |
|
Launchpad user Dave Jones(waveform) wrote on 2022-06-01T12:03:16.289324+00:00 Sure -- I'll try not to drown them in verbiage :) |
|
Launchpad user Lukas Märdian(slyon) wrote on 2022-06-01T13:03:12.328815+00:00 Thank you for all the background information, Dave! I've drafted a PR at upstream netplan, to allow setting the regulatory domain via wpa_supplicant.conf as well as setting it "globally" via 'iw reg set XX', using a systemd service unit. This way it should work for any backend (networkd/wpasupplicant/iwd/NetworkManager), but of course it would be nice if upstream NM would provide an option that we could set from within netplan. |
|
Launchpad user Launchpad Janitor(janitor) wrote on 2022-08-18T23:54:14.180520+00:00 This bug was fixed in the package netplan.io - 0.105-0ubuntu1 netplan.io (0.105-0ubuntu1) kinetic; urgency=medium
-- Lukas Märdian slyon@ubuntu.com Thu, 18 Aug 2022 14:53:33 +0200 |
|
Launchpad user John Neffenger(jgneff) wrote on 2023-04-13T15:54:57.689276+00:00
Yes. I just hit this problem on my new Raspberry Pi 400 with Ubuntu. The Raspberry Pi OS dated February 21, 2023, based on Debian 11 (bullseye), sets my Wi-Fi region code to Canada during installation, and everything works fine. I then tried the Ubuntu 22.10 (Kinetic Kudu) 64-bit desktop image and could no longer find my 5-GHz Wi-Fi access point. It turns out that my 5-GHz Wi-Fi is on channel 149, which is available in Canada but not available when the country code is unset. Channel 149 is not permitted in Japan, Turkey, and South Africa. 1 Adding "cfg80211.ieee80211_regdom=CA" to the end of the following file solved the problem: $ cat /boot/firmware/cmdline.txt It took me forever to find this bug report! The notes here are very helpful. I agree that it would be great to have the country code set automatically when the region is set at installation, and then again in the settings of the Wi-Fi configuration panels. That's certainly the first place I checked while trying to fix it. |
|
Launchpad user Dave Jones(waveform) wrote on 2023-04-13T18:29:58.080477+00:00 Given there doesn't seem much interest in fixing this from the network manager angle (and there's even a question as to whether that's the right place to fix this), I'm going to take a leaf out of the RaspiOS book, and see if I can persuade someone that the installer is the right place to fix this (or more specifically, the new installer, subiquity). That's not going to do anything for lunar which won't be using subiquity on the raspi images, so I'll hold off on adding the project to the "affected" list until lunar's out, but it should be something I can try and push for in the m-animal cycle. @jgneff many thanks for the additional report -- it's extremely useful to have stuff like this I can point to and say "look! It's actually a problem!" |
|
Launchpad user Jerry Vonau(jvonau) wrote on 2023-04-13T20:51:24.927299+00:00 Looking in the root directory of the first partition of the 23.04 beta image contains 'network-config' think this is a user setting file, forgot to set this while testing but I was using wired, as the file contains: This file contains a netplan-compatible configuration which cloud-init willapply on first-boot (note: it will not update the config after the firstboot). Please refer to the cloud-init documentation and the netplan referencefor full details:https://netplan.io/referencehttps://cloudinit.readthedocs.io/en/latest/topics/network-config.htmlhttps://cloudinit.readthedocs.io/en/latest/topics/network-config-format-v2.htmlPlease note that the YAML format employed by this file is sensitive todifferences in whitespace; if you are editing this file in an editor (likeNotepad) which uses literal tabs, take care to only use spaces forindentation. See the following link for more details:https://en.wikipedia.org/wiki/YAMLSome additional examples are commented out belownetwork: ethernets: wifis:wlan0:dhcp4: trueoptional: trueaccess-points:myhomewifi:password: "S3kr1t"myworkwifi:password: "correct battery horse staple"workssid:auth:key-management: eapmethod: peapidentity: "me@example.com"password: "passw0rd"ca-certificate: /etc/my_ca.pemregulatory-domain: GBI'll use wifi for the next install and see how that goes. |
|
Launchpad user Dave Jones(waveform) wrote on 2023-04-13T21:48:33.751556+00:00 netplan added support for configuring the regulatory domain in kinetic and it works pretty nicely (it's one of the things I test before release). However, that's relying on cloud-init to inject the netplan configuration and that's only on the server images -- it's not a solution for the preinstalled desktop images. Having said that ... it might be if cloud-init gets included in the preinstalled desktop images, but that's not happening in lunar as it caused other issues. Still, even if it did that's still a rather command-line / text-configuration-file interface that's nowhere near as "good" as having it integrated into the first time GUI setup (as RaspiOS does). |
|
Launchpad user Ubuntu QA Website(ubuntuqa) wrote on 2023-04-17T14:00:19.147376+00:00 This bug has been reported on the Ubuntu ISO testing tracker. A list of all reports related to this bug can be found here: |
|
Launchpad user John Neffenger(jgneff) wrote on 2023-04-18T14:07:44.005555+00:00 I tried the preinstalled desktop image of Ubuntu 23.04 (Lunar Lobster) Beta last night. It has the same problem, as expected, but it was a bit tricky to fix it directly on the disk image. There are two files called 'cmdline.txt', one in each of the disk's two partitions:
The file is found as '/boot/firmware/cmdline.txt' when running, so I added the command-line argument to the second file. That's the wrong one, though. The partition labeled 'system-boot' is mounted as '/boot/firmware', hiding the directory with the same name on the second partition with the label 'writeable': $ mount | grep boot The correct file to modify on the disk image is the first one, directly in the 'system-boot' partition. By the way, you might wonder why I don't just change the access point's channels, but those high-end 5-GHz channels are the only ones that work well here. The 2.4-GHz channels are saturated by more than 150 access points nearby, and the same with the low-end 5-GHz channels. The high-end channels in Canada from 149 to 161 are far less occupied, fully available (not just for "indoors"), and don't have any Dynamic Frequency Selection (DFS) or Transmit Power Control (TPC) restrictions. John |
|
Launchpad user Jerry Vonau(jvonau) wrote on 2023-04-18T17:11:40.477893+00:00 Circled back with the latest server image using rpi-imager to set the wifi credentials, wifi country does not get populated in network-config but adding that line in works fine. |
|
Launchpad user Floris(bos) wrote on 2023-04-18T22:12:39.312991+00:00
Imager does not fill in the 'regulatory-domain' field in network-config because the last time we tried that the existing Ubuntu editions in the Imager repository did not support the field yet, and reacted badly to it. As in error'ing out instead of just ignoring. |
|
Launchpad user Jerry Vonau(jvonau) wrote on 2023-04-21T13:53:48.094108+00:00
Might want to reconsider that position given the latest release of 22.04 posted on 2023-02-17 |
|
Launchpad user Floris(bos) wrote on 2023-04-21T14:21:07.668017+00:00
Problem is you also still list Ubuntu 20.04 in your Imager repository file at: https://changelogs.ubuntu.com/raspi/os_list_imagingutility_ubuntu.json Suggest you either toss any release that does not support 'regulatory-domain' from the repository first, or backport your fix to that as well. |
|
Launchpad user Jerry Vonau(jvonau) wrote on 2023-04-21T22:39:43.935479+00:00 Shoot, guess the wait will be for 20.04 to be updated. |
ubuntu-server-builder
closed this as not planned
This bug was originally filed in Launchpad as LP: #1951586
Launchpad details
Launchpad user Floris(bos) wrote on 2021-11-19T13:36:18.741333+00:00
It would be nice if netplan offered an option to specify the wifi regulatory domain (country code).
For devices such as the Raspberry Pi you are currently advertising that users can simply setup Ubuntu Server headless by putting the wifi configuration details in cloudinit/netplan's "network-config" on the FAT partition of the SD card: https://ubuntu.com/tutorials/how-to-install-ubuntu-on-your-raspberry-pi#3-wifi-or-ethernet
But an option to set the wifi country code there does not seem to exist, so may not work.
The text was updated successfully, but these errors were encountered: