ASUS RT-BE96U and "Environment: bogus"

[LikeLikeAteMySword]

I recently updated my laptop from PopOS 22.04 to 24.04 and since then, I've been struggling to get Wifi 5, 6, or 6E working. I had no trouble under 22.04 with the wifi, though I did have other problems which is why I upgraded. Apparently the Intel iwlwifi driver cares a lot more about frequencies and regulatory regions than it did before. The laptop is a System76 addw3 with an Intel AX211 wifi chip in it. I managed to get the driver on my side working, but now I'm still struggling because of the ASUS router and Copilot identifies as an issue with the RT-BE96U firmware, which I'm not sure I believe.

I'm running ASUS Merlin 3006.102.6 on my RT-BE96U, which appears to be the latest version and was just released a couple of months ago. When I do a iw dev wlp0s20f3 scan | grep -A5 myssid on my laptop, I see this returned:

root@pop-os:~# iw dev wlp0s20f3 scan | grep -A5 myssid
    SSID: myssid
    Supported rates: 1.0* 2.0* 5.5* 11.0* 18.0 24.0 36.0 54.0
    DS Parameter set: channel 6
    Country: US    Environment: Indoor/Outdoor
        Channels [1 - 11] @ 30 dBm
    Power constraint: 0 dB
--
    SSID: myssid_5G
    Supported rates: 6.0* 9.0 12.0* 18.0 24.0* 36.0 48.0 54.0
    Country: US    Environment: bogus
        Channels [36 - 48] @ 30 dBm
        Channels [52 - 64] @ 24 dBm
        Channels [100 - 144] @ 24 dBm
--
    SSID: myssid_6G
    Supported rates: 6.0* 9.0 12.0* 18.0 24.0* 36.0 48.0 54.0
    TIM: DTIM Count 0 DTIM Period 1 Bitmap Control 0x0 Bitmap[0] 0x0
    Country: US    Environment: bogus
        Extension ID: 254 Regulatory Class: 131 Coverage class: 0 (up to 0m)
        Extension ID: 254 Regulatory Class: 132 Coverage class: 0 (up to 0m)

Apparently, the "Environment: bogus" is causing the network not to be detected properly.

I'm able to work around it by forcing Wifi 5 and Wifi 6 networks to 160 MHz and hard-coding the PSC channel (keep in mind I have no idea what PSC or DFS means), but I'd like to use the 320 MHz for my Meta Quest 3.

What is the "Environment:" thing for anyway? Is there a way for me to set it to "Indoor" like my 2.4GHz network?

 

[OzarkEdge]

I'm out of my depth here...

AI (is intel ax211 compatible with ubuntu 24.04?): ... users often report issues like driver failures (error -110), connectivity drops, and instability, especially with newer kernels or specific BIOS settings, requiring firmware updates or workarounds for the iwlwifi driver, so compatibility isn't always seamless and might need troubleshooting.

AI suggests to check dmesg: Use dmesg | grep iwlwifi to look for error messages.

OE

 

[LikeLikeAteMySword]

Yeah I heavily relied on Copilot to get me to the point that the card would detect the 6 GHz network at all, but it's insisting that it's some sort of Atheros firmware bug, and I have my doubts.

 

[LikeLikeAteMySword]

An update for anyone who comes across this. Disclaimer: this gets into areas of radio and wireless technology that I have no familiarity with at all, and a lot of these answers are driven by Microsoft Copilot. Further, System76 is still working on investigating things on their end, and I have only verified a problem on my System76 addw3 (Adder version 3).

TL;DR: Copilot says that the Intel iwlwifi driver will disable 5 GHz and 6 GHz bands if an access point has 320 MHz enabled, as of the latest Linux kernel version (I'm running PopOS 24.04, so 6.17 for me). This doesn't happen in Windows.

Long version - apparently, what Broadcom does on their chip (this isn't ASUS, this is a Broadcom thing) is share the same "PHY chain" (don't ask me what that means) for both Wifi 6 and Wifi 7. Thus, when you enable Wifi 7, it enables "EHT Operation/Capabilities", and a "320 MHz operating class" (among other things). This gets enabled when you select "20/40/80/160/320 MHz" in the 6 GHz section of the wireless menu. Both 5 and 6 GHz use the same radio, so these capabilities get broadcast across both bands. This shows up as some kind of flag when you do a "wl -i wl2 beacon_info" (I'd post the output here, but I'm not sure how much of that is personal info, since much of it is hex, and I don't have time to dig through it and remove it all).

These flags then appear to the iwlwifi driver. You can check what the wifi chip on the Linux laptop supports by doing a "iw phy0 info" (again, I'd post the output, but it might have personal data). In the past (PopOS 22.04), the Intel driver would simply ignore these flags. Under Windows, the driver still DOES ignore these flags. Supposedly, though, under FCC regulations within the United States, Intel can't ignore them. The regulations state that the wifi card is not supposed to associate with a router advertising EHT + other stuff because the Intel AX211 card doesn't explicitly support EHT + other stuff.

In other words, the Intel AX211 chip on the System76 addw3 laptop is not permitted to associate to the ASUS RT-BE96U router that advertises a capability that the chip does not support.

Now, you might be wondering why it is that the same hardware, lacking the same EHT capability, is somehow allowed to associate with the same router, with the same EHT advertisement, on Windows but not on Linux, and all the questions that raises. Copilot says the answer is that Intel "owns the whole driver stack," whereas the kernel maintainers own part of the Linux stack, and the stack, as a whole, is certified for FCC operation. I'm not sure I buy that argument. However, we frequently get the short end of the stick in the Linux world anyway. Intel labeled this whole thing a "compliance issue" and so it will never be fixed.

This sucks because I actually DO have equipment that supports 320 MHz Wifi 7, and the extra bandwidth is really nice, but I'll have to make do with switching 320 MHz on and off every time I use it.

Now, again, this is still all under investigation and is only based on experimentation with my particular setup + Copilot guiding me in interpreting what I was looking through. AI frequently hallucinates. I also point out that the Intel driver has some bad behavior to start with - to get the AX211 to work with even 5GHz using the 160 Mhz setting, I had to add the following options in /etc/modprobe.d/iwlwifi.conf (creating the file since it didn't exist):

# /etc/modprobe.d/iwlwifi.conf
# iwlwifi will dyamically load either iwldvm or iwlmvm depending on the
# microcode file installed on the system.  When removing iwlwifi, first
# remove the iwl?vm module and then iwlwifi.
remove iwlwifi \
(/sbin/lsmod | grep -o -e ^iwlmvm -e ^iwldvm -e ^iwlwifi | xargs /sbin/rmmod) \
&& /sbin/modprobe -r mac80211


# --- Added to fix AX211 regulatory issues ---
options iwlwifi disable_11ax=0
options iwlwifi power_save=0
options cfg80211 ieee80211_regdom=US

The bad news is that one radio means one PHY chain, and so even though the 5 GHz network is not logically separate, it also disappears because it's using the same radio.

The solution for me so far is to switch off 320 MHz and anything remotely having to do with 320 MHz on the ASUS Merlin side, and hard set the "PSC channel" (I don't know what those are either) as high as possible. That's about as far as close as I'm going to get to working again, and even then, I have to randomly change channels quite a bit. Copilot says I can get a new router to fix it. I doubt it.

I hope this helps someone out there that might be struggling with the same problem.

So, in conclusion, Intel sucks. That is all.