RTL8822BE 5GHz AP mode not supported?
mid-kid opened this issue · comments
Before the r8822be staging driver got removed with linux 5.2, I could use 5GHz AP mode with this adapter just fine. Now, hostapd fails with the following message:
Channel 36 (primary) not allowed for AP mode, flags: 0x853 NO-IR
wlan0: IEEE 802.11 Configured channel (36) not found from the channel list of current mode (2) IEEE 802.11a
wlan0: IEEE 802.11 Hardware does not support configured channel
Could not select hw_mode and channel. (-3)
Is 5GHz AP mode not supported anymore with this driver?
Out of curiosity, I've applied this patch (I have no clue where reg_rule->flags is being set):
--- a/regd.c
+++ b/regd.c
@@ -283,7 +283,7 @@ static void rtw_regd_apply_beaconing_flags(struct wiphy *wiphy,
ch->flags &= ~IEEE80211_CHAN_DISABLED;
- if (!(reg_rule->flags & NL80211_RRF_NO_IR))
+ //if (!(reg_rule->flags & NL80211_RRF_NO_IR))
ch->flags &= ~IEEE80211_CHAN_NO_IR;
}
}
And hostapd works like it used to, now, with devices connecting to it just fine. Of course, this isn't an acceptable solution, but it convinces me that it's not a hardware limitation.
Was it just the low-band of 5G that failed? How about channels 120, or 157? Do they also fail with the unaltered code?
IEEE80211_CHAN_NO_IR means "do not initiate radiation, this includes sending probe requests or beaconing."
Is channel 36 allowed in your regulatory zone?
Running iw list tells me the "No IR" thing for all 5GHz frequencies, not a single channel is allowed according to it. I'm in western europe, and my main router transmits over 5GHz just fine (center frequency of 5500MHz), though I'm not informed about regulations in my area.
How are the regulatory zones determined in the kernel? Is it based on some region setting, the hardware or something else? Maybe my kernel's misconfigured? I'm running sys-kernel/gentoo-kernel-5.9.11, which basically inherits fedora's stock config with minor tweaks.
There is a regulatory daemon that supplies that information based on the region code supplied by the driver. Your card's EFUSE may be supplying a code other than EU. Check dmesg for any hints.
dmesg didn't really give any hints aside from cfg80211 loading some certificates. What did, however, was checking if there was any package with "regul" in the description, which led me to wireless-regdb and crda, which I'm sure you know (but I didn't) are the two packages involved in informing the kernel about these regulations.
Checking the archlinux package, it seems they call a script from udev when the module is loaded, to use iw reg set <country code>. Running this with the appropriate country code for my region fixed this issue without requiring any patches, but doesn't persist across reboots. On a fresh boot, iw reg get returns country 00: DFS-UNSET, both globally and for my device. To get a list of regions, the command regdbdump /usr/lib/crda/regulatory.bin can be used.
I wonder why Gentoo doesn't provide a method of setting the regulatory region, as neither any of the init scripts nor netifrc seem to have any option for this, but for now I'll just set it from an /etc/local.d script, and bring this issue up to the Gentoo devs.
Anyway, thanks for the hints.
No, that is not a script. He modified and rebuilt his kernel. Given that you asked this question, I would suggest that you not try this method.
@lwfinger Which kernel? (excuse my curiosity; I'm enthusiastic) as I'd like to know if it is hardware limitation or not.
Have you installed the crda package? It contains the rules for your region. I have no idea what kernel he used. In addition, that patch violates the wireless rules for his jurisdiction. If I did that, the FCC police might be visiting me. There are rules for the 5 GHz band to keep the wifi users from interfereing with radar, etc.
I want no trouble with the law.
The kernel doesn't matter. To bypass the restrictions you can either look for that line in any recent linux kernel and comment it out, or build a kernel with CONFIG_CFG80211_REQUIRE_SIGNED_REGDB=n and make your own wireless-regdb regulatory.db.
But you seem misguided. See my comment above about how iw reg set <country> worked to fix the allowed channels in my country, and try that first. You can of course select any country's regulations.
@mid-kid Actually I tried but I think it didn't work for me!
Here is the footage.
I issued the command sudo iw reg get and the output is
Now, the command sudo iw reg set CA and the previous command return.
Notice it didn't affect the physical phy#0 interface. The result of creating an AP by issuing sudo create_ap --config ./create_ap_5.conf --daemon --logfile ./log/wifi3 where create_ap_5.conf cats as
CHANNEL=140
GATEWAY=10.0.0.1
WPA_VERSION=2
ETC_HOSTS=0
DHCP_DNS=gateway
NO_DNS=0
NO_DNSMASQ=0
HIDDEN=0
MAC_FILTER=0
MAC_FILTER_ACCEPT=/etc/hostapd/hostapd.accept
ISOLATE_CLIENTS=0
SHARE_METHOD=nat
IEEE80211N=0
IEEE80211AC=0
HT_CAPAB=[HT40+]
VHT_CAPAB=
DRIVER=nl80211
NO_VIRT=0
COUNTRY=
FREQ_BAND=5
NEW_MACADDR=
DAEMONIZE=0
NO_HAVEGED=0
WIFI_IFACE=new1
INTERNET_IFACE=enp0s31f6
SSID=MyAccessPoint
PASSPHRASE=12345678
USE_PSK=0
The log file sudo cat ./log/wifi3
To bypass the restrictions you can either look for that line in any recent linux kernel and comment it out, or build a kernel with CONFIG_CFG80211_REQUIRE_SIGNED_REGDB=n and make your own wireless-regdb regulatory.db.
@mid-kid Could you provide more information on which file I have to edit?
My kernel version using uname -r is
6.0.12-76060006-generic
The source code directory embeds multiple file there /usr/src/linux-headers-6.0.12-76060006-generic/kernel/
bounds.s debug/ futex/ Kconfig.freezer kcsan/ module/ sched/
.bounds.s.cmd dma/ gcov/ Kconfig.hz livepatch/ power/ time/
bpf/ entry/ gen_kheaders.sh Kconfig.locks locking/ printk/ trace/
cgroup/ events/ irq/ Kconfig.preempt Makefile rcu/
Use iw list to figure out if your adapter supports the frequency and channel at all.
Please refrain from pasting entire logs, use a pasting service if you need to share this much text.
And do your own diligence of trying to read it at all before anything.
Anyway, no IR means it's restricted in your country, which channel 36 happens to be. Just change the iw region to a different one.
Sorry, I am a newbie and I'm not much aware of what all of the output means therefore I have to provide it all. Using pastebin is better to not condensate the discussion.
I found these files
./.config:CONFIG_CFG80211_REQUIRE_SIGNED_REGDB=y
./include/generated/autoconf.h:#define CONFIG_CFG80211_REQUIRE_SIGNED_REGDB 1
./include/config/auto.conf:CONFIG_CFG80211_REQUIRE_SIGNED_REGDB=y
Editing these files to the opposite that is to 'n', '0', and lastly, 'n', requires rebuilding right?
Please google on how to build a kernel from source. The kernel-headers are just the headers, not the full source.
Also disabling the config option would just allow you to load a custom regdb, so you'd have to build that too.
You're in way over your head, and I'd advise leaving this be.
I agree rhat generating a kernel would be beyond his abilities, at least at the moment.
That said, there is a problem with the regulatory information in the rtw_8852be. I also have an Intel 7260, and for a US regulatory domain, it shows the first 4 5GHz channels without the No IR annotation, but the 8852be does. I will contact Realtek, and see if we are missing something.
I don't know anything about this, but don't you need to set the COUNTRY field in create_ap_5.conf ?
That's the same as using iw reg set globally. Wasn't aware of that option either, though.
I agree rhat generating a kernel would be beyond his abilities, at least at the moment.
That said, there is a problem with the regulatory information in the rtw_8852be. I also have an Intel 7260, and for a US regulatory domain, it shows the first 4 5GHz channels without the No IR annotation, but the 8852be does. I will contact Realtek, and see if we are missing something.
Why would it be so? If brief steps were provided I would re-generate the kernel. Anyway, it's in my to-do list.
There's no brief steps and it's heavily distribution- and setup-dependent.
It's okay. Why don't you describe the "heavily distribution- and setup-dependent" instead of stating it?
I am aware where to fill in the gaps.
Because it's not brief and you'll have to google. Anything you'll find there will be easier and more thorough than anything I can explain here without knowing what kind of system you're using.
If you use 'sudo iw reg set US' (or whatever country you want), the PASSIVE-SCAN is no longer set, and 'iw list' no longer shows the "No IR" flags. Using "EU" fails, but individual countries such as "DE" or "FR" work.
I thought I did that last week, but I must have done it wrong.