GL-BE9300 emits Environment: bogus in Country IE — breaks WCN785x/FastConnect 7800 (ath12k) regulatory unlock

Router
1

GL-BE9300 emits Environment: bogus in Country IE — breaks WCN785x/FastConnect 7800 (ath12k) regulatory unlock

Firmware: 4.9.1 snapshot (also confirmed on 4.9.0 / 2026-05-21)

Issue:
All BSSes on the BE9300 (2.4G, 5G, 6G, MLO VAPs) advertise Country: DE Environment: bogus in beacon Country IEs. This is an invalid Environment field per IEEE 802.11-2020 §9.4.1.17 — valid values are I (0x49, Indoor), O (0x4F, Outdoor), or X (0x58, non-country).

Impact:
Qualcomm WCN785x (FastConnect 7800, ath12k driver, firmware WLAN.HMT.1.1.c7-00108) is a self-managed regulatory device — it determines its regulatory domain from AP beacon Country IEs, not from OS hints. It correctly rejects the malformed IE and stays locked at country 00: DFS-UNSET with NO-80MHZ, NO-160MHZ, NO-320MHZ restrictions, capping throughput at ~288 Mbps despite being associated to the 6 GHz MLO link.

Evidence:

# All GL-BE9300 BSSes:
Country: DE    Environment: bogus

# Neighbouring non-GL AP for comparison:
Country: US    Environment: Indoor/Outdoor

# Client phy regulatory state while associated to GLHme-MLO:
phy#0 (self-managed)
country 00: DFS-UNSET
    (2402 - 2472 @ 40), NO-80MHZ, NO-160MHZ, NO-320MHZ

Root cause:
The QCA qcawificfg80211 driver / hostapd config generation is setting country3=0x20 (space character) for all radios (wifi0/wifi1/wifi2). This renders as bogus in iw and is rejected by spec-compliant clients.

Fix required:
Set country3=0x49 (Indoor) in the QCA hostapd/wifi config generation for all three radios.

Confirmation this is the root cause:
Previous card (MT7925/mt76) connected to the same BE9300 at multi-Gbps MLO speeds — mt76 accepts the global kernel regdomain and ignores the bogus IE. WCN785x/ath12k is spec-compliant and rejects it. The router is the non-compliant party.

1 Like
Flint 3 (GL-BE9300) Firmware
2

Hi

We checked the beacon frames on a BE9300 running v4.9.0 Release 5, and found that the Environment field is set to 0x04, which corresponds to "Annex E, Table E-4 (Global operating classes)" and is compliant with the IEEE 802.11 specification (see item 5 below):

image

dot11CountryString OBJECT-TYPE
	SYNTAX OCTET STRING (SIZE(3))
	MAX-ACCESS read-only
	STATUS current
	DESCRIPTION
		"This is a control variable.
		It is written by the SME.
		Changes take effect for the next MLME-START.request primitive.

		This attribute identifies the country or noncountry entity in which the station is operating. If it is a country, the first two octets of this string is the two character country code as described in document ISO 3166-1. The third octet is one of the following:

		1. an ASCII space character, if the regulations under which the station is operating encompass all environments for the current frequency band in the country,

		2. an ASCII 'O' character, if the regulations under which the station is operating are for an outdoor environment only, or

		3. an ASCII 'I' character, if the regulations under which the station is operating are for an indoor environment only.

		4. an ASCII 'X' character, if the station is operating under a noncountry entity. The first two octets of the noncountry entity is two ASCII 'XX' characters.

		5. the hexadecimal representation of the Operating Class table number currently in use, from the set of tables defined in Annex E, e.g., Table E-1 is represented as x'01'."
	::= { dot11StationConfigEntry 23 }

Reference: https://www.ieee802.org/11/802.11mib.txt

May try to test on Windows using the vendor-supplied driver to see whether the same issue occurs.

1 Like