Is there no way to set (and persist) the wireless regulatory domain in OSMC for the Pi 3B ?
I have no option but to operate on wifi channel 13 as the Wifi is provided as part of the serviced
apartment deal at my current dwelling. There is no ethernet connection in the place i can access. All the APs are in the apartment corridors and their connection points are recessed into the ceiling behind the units
I can see the wifi option in MyOSMC and I can see the low channel APs from other buildings ,but the one I need to access happens to be on 13 . spoke to the IT guy , completely see his rationale and why he cant change things to suit “just me” (hes done a proper job - frequency plan - lock mac to AP etc to ensure no one AP gets overloaded)
If not I guess I have to go back to the dark side running kodi under raspbian :-/
osmc@dalek:~$ sudo systemctl status systemd-udevd.service
● systemd-udevd.service - udev Kernel Device Manager
Loaded: loaded (/lib/systemd/system/systemd-udevd.service; static; vendor pre
Active: active (running) since Sat 2017-12-30 16:06:39 EST; 32min ago
Main PID: 213 (systemd-udevd)
Status: "Processing with 16 children at max"
Dec 30 16:06:39 dalek systemd: Starting udev Kernel Device Manager...
Dec 30 16:06:39 dalek systemd: Started udev Kernel Device Manager.
This is an issue that’s existed for some time that I haven’t really got around to addressing yet, but it does want looking at.
By default, OSMC does not bundle the crda package and this seems to be causing problems. It appears that it would be better to use the kernel’s built in regulatory rules instead. If this is done, it needs to be done for all kernels.
As we update the kernel very regularly, the fact that we need to build a kernel each time we update regulatory rules doesn’t seem to be a problem.
So I believe all we need to do is:
enable CONFIG_CFG80211_INTERNAL_REGDB for all kernels
add a build action to update net/wireless/db.txt. This will ensure that older kernels still have the latest regulatory data.
if I understand this issue well, for my situation:
if I am running 4.9.29-10-osmc with some RTL 8812au USB dongle (identified as Product: Edimax AC600 USB, in fact it is Edimax EW-7811UAC), I cannot use channels >100.
Region is unset/98, iw list says
* 5320 MHz  (20.0 dBm) (no IR)
* 5500 MHz  (disabled)
* 5520 MHz  (disabled)
* 5540 MHz  (disabled)… etc
(/lib/modules/4.9.29-10-osmc/kernel/drivers/net/wireless/8812au.ko, version: v4.3.20_16317.20160108)
CRDA does nothing…
sudo iw reg set does nothing - still country 98: DFS-UNSET…
Am I correct? Or can do anything about using channels>100 which is supported by my router, country etc…
I must correct myself, partially… after some reboots I was finally able to set country by CRDA, so iw reg get shows correct country… however, iw list still says that channels>100 are disabled… why, oh why?
Is there any way how to examine, if disabled channels are due to firmware of the dongle or due to driver in OSMC? Ok, I can take it and connect it to the windows box… will try, but I cannot do it in remote way instantly
Trying it on Windows is worth a shot. If you see extra channels, it’s the Linux driver and if you don’t, well… it could still be the driver (or the hardware).
@fzinken In Europe the channels >= 149 are reserved for Short Range Devices, as the Wikipedia table shows. The relevant ETSI document for 5 GHz WiFi seems to be ETSI EN 301 893:
For the purposes of the present document, the terms and definitions given in Directive 2014/53/EU [i.1] and the following apply: 5 GHz RLAN bands: total frequency range that consists of the 5 150 MHz to 5 350 MHz and the 5470 MHz to 5 725 MHz sub-bands