Wallys DR9074-6E(PN02.7) QCN9074 refuses to work on 6GHz band

Tue Nov 22 07:14:36 PST 2022

I finally got it to work! Performance wise it is not terrible and now
I am moving from driver perimeter to hostapd perimeter. Running stable
for the last 24hrs, no drops.
160Mhz width on channel 5, client reports 2402/2402 (Mbps) which is
max since intel AX210 is a 2 stream device versus 4 on QCN. In
practice with iperf3 between NAS & my PC connected to the SoftAP and 4
threads:

[SUM]   0.00-10.00  sec  1.13 GBytes   972 Mbits/sec                  sender
[SUM]   0.00-10.00  sec  1.13 GBytes   972 Mbits/sec                  receiver

1669065192.525964: Mode: IEEE 802.11a  Channel: 5  Frequency: 5975 MHz
1669065192.525965: nl80211: Set freq 5975 (ht_enabled=0,
vht_enabled=0, he_enabled=1, eht_enabled=0, bandwidth=160 MHz,
cf1=6025 MHz, cf2=0 MHz)

Not that it is specific to ath11k driver but in case anyone is looking
for some information getting it up required solving regulatory domain
issues, board_id issues and finally hostapd issues - maybe not issues
but considerations.

- First I got a list of channels off the internet wrongly listing PSC
channels as 1, 17 , 33 etc. Hostapd channel=0 with ACS was setting
channel 33 as optimal. I assumed this is a PSC channel wrongly.
Comparing live packet dumps from AXE75 and QCN9074 I started spotting
those nuances and a problem was already creating itself. As explained
this is a single band module so it does not have any 2.4/5G channels
to assist with broadcasting and 6E has only 1 active method of in-band
discovery - PSC. This made discovery tricky.
- Needed to update driver of AX210 to even discover commercial AXE75,
so also client required work.
- Then I compiled hostapd with FILS support but it is off by default.
You need to specify max_interval to turn it on which assists PSC with
passive discovery. fils_discovery_min_interval=20,
fils_discovery_max_interval=100. Yes, I understand we discourage use
of the 6E band for probing but if this is the only band it should be
on by default.
- op_class= it looks like you can set anything between 131-136, it has
meaning only to enable 6E but it does not preset channel/center
frequency or anything based on the channel number/PSC or not. I set
op_class=134 channel=5, he_oper_centr_freq_seg0_idx=15 (for 160Mhz)
and he_oper_chwidth=2 (chwidth can be anything, it is ignored). With
other 3 parameters set kernel is not reporting errors and AP is
functioning. Don't use ASC if you have a single band module due
in-band discovery issues.
- good thing it is working well in bridge mode incl. dhcp broadcasts
- in case anyone wonders, AP operates in US reg domain since firmware
still does not have proper lower 6E band support for EU, it disables
6E with iw reg set BE/DE or any non US country. Client is using LAR
and setting itself to BE. If you don't need DFS (not needed in 6E)
etc. country_code, ieee80211d don't need to be set. If you set it to
anything else than US you fail at start -> firmware does not have reg
domain for 6E in any other region than US. That consumed some time to
discover, understand and compilation of various kernel options for
self-managed setting.

So to conclude on this topic here likely most of the manufacturers of
these modules in China don't have tools/licenses for QCA
tools/software hence modules come not fused. Ask before you buy to
confirm. Likely mostly these are only PCB/assembly shops. I gave up
trying since support discussions were going nowhere. Secondly there's
been changes to 6E so some information out in the internet is not
accurate and greatly confusing between multi-band & single-band
scenarios. Most assume you work in a multi-band environment. Thirdly,
very early software/firmware with quite dynamic regulatory footprint -
expect differences to reality.

In any case working hostapd.conf for single band 6E which is now
discover-able in a reasonable time (20-30 seconds from AP start).

grep "^[^#]" hostapd.conf
interface=wlp1s0
bridge=br0
logger_syslog=-1
logger_syslog_level=0
logger_stdout=0
logger_stdout_level=0
ctrl_interface=/var/run/hostapd
ctrl_interface_group=0
ssid=XXXXXXX
hw_mode=a
channel=5
op_class=134
preamble=0
macaddr_acl=0
auth_algs=3
ignore_broadcast_ssid=0
ap_isolate=1
broadcast_deauth=0
ieee80211ax=1
he_oper_centr_freq_seg0_idx=15
he_6ghz_reg_pwr_type=0
eapol_key_index_workaround=0
eap_server=0
own_ip_addr=127.0.0.1
wpa=2
wpa_passphrase=XXXXXXXXX
wpa_psk_radius=0
wpa_key_mgmt=SAE
rsn_pairwise=CCMP
group_cipher=CCMP
wpa_group_rekey=1800
rsn_preauth=1
ieee80211w=2
group_mgmt_cipher=AES-128-CMAC
assoc_sa_query_max_timeout=10000
sae_pwe=2
fils_hlp_wait_time=30
fils_discovery_min_interval=20
fils_discovery_max_interval=100
proxy_arp=1
stationary_ap=1

On Sun, 20 Nov 2022 at 09:13, Mariusz <enebeo at gmail.com> wrote:
>
> I also got my hands on AXE75 which is a 6E router and I am able to get
> QCN9074 work in STA mode.
>
> With 160Mhz it did not work but it may be anything. However with 80Mhz
> I am able to get a successful connection fully authenticated with
> WPA3. So radio wise it operates in 6Ghz band after driver patch with
> board_id=0xa2. Now I'm trying to understand why it still does not work
> in AP mode.
>
> root at s4:/home/angel# wpa_cli status
> Selected interface 'wlp6s0'
> bssid=1c:61:b4:c8:93:f4
> freq=6115
> ssid=test
> id=0
> mode=station
> wifi_generation=6
> pairwise_cipher=CCMP
> group_cipher=CCMP
> key_mgmt=SAE
> pmf=2
> mgmt_group_cipher=BIP
> wpa_state=COMPLETED
> ip_address=192.168.6.123
> address=c4:4b:d1:d0:00:7e
> uuid=07aaca38-a259-53ef-b12b-bb4cf5dad8d8
>
> On Sat, 19 Nov 2022 at 16:16, Robert Marko <robert.marko at sartura.hr> wrote:
> >
> > On Sat, Nov 19, 2022 at 2:40 PM Mariusz <enebeo at gmail.com> wrote:
> > >
> > > I have contacted Wallys again but I am skeptical about resolution.
> > > They don't consider board_id an issue and provided the same response,
> > > on integrated systems it is due the bootloader to set it properly so
> > > it is not fused and obviously not included in x86 scenario.
> >
> > Hi, this is not really the case, how would the bootloader set the board_id
> > which is supposed to be fused on the device so FW would report the correct one?
> > You can only workaround that by hardcoding it in the driver or on non-x86
> > in DTS and force-loading the correct BDF that way.
> >
> > > Since this
> > > is a private project I doubt QCA will support my efforts and free
> > > access to their portals gives nothing. Found online some SDK for
> > > version ath10k/IPQ8074 and athtestcmd to deal with OTP/fusing but
> > > that's far beyond home project effort.
> > >
> > > Tried also to compile it in OpenWRT with moderate success. ath11ko /
> > > qrtr.ko modules are built but the module never goes past power on
> > > success.
> > > mhi mhi0: Requested to power ON
> > > mhi mhi0: Power on setup success
> > > mhi mhi0: Wait for device to enter SBL or Mission mode
> > >
> > > Even the newest kernel in OpenWRT master development branch 5.16 is
> > > quite behind and backporting anything is another non-trivial task.
> >
> > ath11k won't work in OpenWrt master currently, I have been supporting IPQ807x
> > and recently PCI version as well out-of-tree with hopes of getting it soon into
> > OpenWrt once 6.1 backports become available as that gets rid of like 300-ish
> > backported patches.
> >
> > Regards,
> > Robert
> > >
> > > On Fri, 18 Nov 2022 at 15:06, Sven Eckelmann <sven at narfation.org> wrote:
> > > >
> > > > On Friday, 18 November 2022 13:48:43 CET Mariusz wrote:
> > > > > Mine is from a different supplier - Wallys - and I bought it 2 weeks
> > > > > ago but not sure how old their stock is. PCB looks slightly different
> > > > > than Pinapple's. Is it likely to have the same issue?
> > > >
> > > > It definitely has the same issue (because you reported that board_id is
> > > > 255/0xff) but I have no idea whether Wallytech ever fixed it. At least I was
> > > > never in contact about this problem with them. But sending around precompiled
> > > > kernel module binaries (for an unknown kernel build), with some hacks to fix
> > > > their hardware production errors (missing module id fusing in the OTP for
> > > > their separately sold modules), doesn't make me confident that they are able
> > > > to solve this problem correctly.
> > > >
> > > > In their defense, QCA doesn't make it really easy. It seems like their
> > > > reference designs with Pine on 6Ghz are (mostly?) for (embedded Linux) APs
> > > > which use the normal flash (NOR or NAND) to store the calibration data. And
> > > > for these devices, they use the devicetree (or various other hacks) to load
> > > > the correct board data.
> > > >
> > > > Wallystech has to find the correct document on createpoint which describes the
> > > > process. It was something like "module" "board id" "fusing". But it is not the
> > > > "Board ID Fusing for 802.11ax WLAN AP Chipsets" which only describes the way
> > > > how you would to it for thei internal wifi of the IPQ807x/IPQ60xx/... SoC.
> > > > You/they are searching for the corresponding document for Pine IPQ9074. Most
> > > > likely hidden in some QDART documents.
> > > >
> > > >
> > > > Regarding the problem that some countries are not allowing 6GHz: You have to
> > > > either get a firmware from QCA which has it enabled or you modify the BDFs
> > > > ("board-" files in the board-2.bin) to enable 6GHz in the (enabled) embedded
> > > > REGDB of the BDFs for the specific country. Unfortunately, the data structures
> > > > of the BDF are not officially documented and you would need an official QSDK/
> > > > ATH.11.X release from QCA to fetch the bdf2txt.py, txt2bdf.py and the
> > > > corresponding template for your BDF to extract and modify it.
> > > >
> > > > Kind regards,
> > > >         Sven
> > >
> > > --
> > > ath11k mailing list
> > > ath11k at lists.infradead.org
> > > http://lists.infradead.org/mailman/listinfo/ath11k
> >
> >
> >
> > --
> > Robert Marko
> > Staff Embedded Linux Engineer
> > Sartura Ltd.
> > Lendavska ulica 16a
> > 10000 Zagreb, Croatia
> > Email: robert.marko at sartura.hr
> > Web: www.sartura.hr