QCN 9074 support on OpenWRT x86

Installing and Using OpenWrt
1

Hi all,

I've been working with a QCN9074 (ath11k) Wi-Fi chip I purchased a while back to set up a new router

I've been going through all the various threads scattered through these forums and on Reddit and have gotten as far as getting the kernel to initialize the device, upload the necessary firmware blobs to the card and have the device appear in LuCI

However nothing I seem to do makes any change to the card itself. In LuCI the Wireless Overview simply shows "Device is not active" for radio0 with my "test AP" listed as "Wireless is not associated"

No amount of changing settings in either option, restarting or even scanning for devices seems to cause it to do anything. I'm also not able to see any kind of output on dmesg (no kernel oops messages or other possible bugs to search for)

Has anyone else had any luck with setting up one of these cards on an x86 machine and might be able to point me in the right direction?

2

Small update:

I deleted the Wi-Fi point and added a new one, the transmit power seems to be locked at 255 dBM or "driver default" and lists current power "unknown"

Setting it to either mode causes no changes.

The country code seems to default to "driver default". Changing it to "00 - World" causes a single line to be output in dmesg

[196569.422952] ath11k_pci 0000:02:00.0: Failed to set the requested Country regulatory setting

Changing it to "US" seems not to cause any errors to appear. Nor does setting it back to "driver default"

Changing it to a random country such as "AU - Australia" does trigger a kernel oops, but does not provide any further insight

[196669.983294] ------------[ cut here ]------------
[196669.983510] WARNING: CPU: 0 PID: 1715 at ath11k_reg_update_chan_list+0x24b/0x270 [ath11k]
[196669.983900] Modules linked in: pppoe ppp_async nft_fib_inet nf_flow_table_ipv6 nf_flow_table_ipv4 nf_flow_table_inet ath11k_pci ath11k pppox ppp_generic nft_reject_ipv6 nft_reject_ipv4 nft_reject_inet nft_reject nft_redir nft_quota nft_objref nft_numgen nft_nat nft_masq nft_log nft_limit nft_hash nft_flow_offload nft_fib_ipv6 nft_fib_ipv4 nft_fib nft_ct nft_counter nft_chain_nat nf_tables nf_nat nf_flow_table nf_conntrack mac80211 lzo cfg80211 slhc r8169 qrtr_mhi qrtr qmi_helpers nfnetlink nf_reject_ipv6 nf_reject_ipv4 nf_log_syslog nf_defrag_ipv6 nf_defrag_ipv4 mhi lzo_rle lzo_decompress lzo_compress libcrc32c igc forcedeth e1000e crc_ccitt compat bnx2 i2c_dev ixgbe e1000 amd_xgbe mdio nls_utf8 ena sha512_ssse3 sha512_generic seqiv jitterentropy_rng drbg michael_mic hmac cmac crypto_acompress nls_iso8859_1 nls_cp437 igb vfat fat button_hotplug tg3 ptp realtek pps_core mii
[196669.987275] CPU: 0 PID: 1715 Comm: hostapd Not tainted 5.15.120 #0
[196669.987554] Hardware name: HP HP ProDesk 400 G4 SFF /82A2, BIOS P08 Ver. 02.02 01/11/2017
[196669.987913] RIP: 0010:ath11k_reg_update_chan_list+0x24b/0x270 [ath11k]
[196669.988240] Code: 06 fe ff ff 41 c7 87 48 51 00 00 00 00 00 00 e9 f6 fd ff ff 49 8d bf 78 06 00 00 be d0 07 00 00 e8 5a 40 5f e1 e9 f3 fd ff ff <0f> 0b bb ea ff ff ff eb a3 bb f4 ff ff ff eb 9c 48 83 cf ff e9 64
[196669.989015] RSP: 0018:ffffc90001907b48 EFLAGS: 00010246
[196669.989239] RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffff888105900f00
[196669.989540] RDX: 0000000000000001 RSI: ffff8881065c0508 RDI: ffff8881065c2060
[196669.989839] RBP: ffffc90001907b78 R08: 00000000000012b8 R09: 0000000020000000
[196669.990143] R10: 0000000000000080 R11: ffff8881065c3e78 R12: ffff8881065c08c0
[196669.990450] R13: ffff8881065c04d8 R14: ffff8881065c0508 R15: ffff8881065c2060
[196669.990756] FS:  00007ff2142f0b48(0000) GS:ffff88812c200000(0000) knlGS:0000000000000000
[196669.991097] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[196669.991341] CR2: 00007ff213d53250 CR3: 00000001032c8004 CR4: 00000000003706f0
[196669.991641] Call Trace:
[196669.991752]  <TASK>
[196669.991849]  ? show_regs.part.0+0x1e/0x24
[196669.992027]  ? show_regs.cold+0x8/0xd
[196669.992189]  ? __warn+0x74/0xf0
[196669.992331]  ? ath11k_reg_update_chan_list+0x24b/0x270 [ath11k]
[196669.992594]  ? report_bug+0x86/0xa0
[196669.992758]  ? handle_bug+0x38/0x90
[196669.992911]  ? exc_invalid_op+0x18/0x70
[196669.993076]  ? asm_exc_invalid_op+0x1b/0x20
[196669.993255]  ? ath11k_reg_update_chan_list+0x24b/0x270 [ath11k]
[196669.993508]  ath11k_mac_tx_mgmt_pending_free+0x3ad0/0x7d60 [ath11k]
[196669.993780]  drv_start+0x2e/0x50 [mac80211]
[196669.993964]  ieee80211_do_open+0x329/0x770 [mac80211]
[196669.994186]  ieee80211_do_open+0x74b/0x770 [mac80211]
[196669.994416]  __dev_open+0xdc/0x1a0
[196669.994565]  __dev_change_flags+0x189/0x1f0
[196669.994743]  ? move_addr_to_user+0x3e/0x90
[196669.994919]  dev_change_flags+0x22/0x60
[196669.995084]  devinet_ioctl+0x3b2/0x7d0
[196669.995245]  ? iovec_from_user.part.0+0xd3/0x180
[196669.995440]  inet_ioctl+0x15d/0x190
[196669.995590]  ? netdev_name_node_lookup_rcu+0x63/0x80
[196669.995804]  ? dev_get_by_name_rcu+0x9/0x20
[196669.995987]  ? dev_ioctl+0x2a9/0x470
[196669.996141]  sock_ioctl+0x1dc/0x320
[196669.996295]  __x64_sys_ioctl+0x42c/0x9b0
[196669.996468]  do_syscall_64+0x42/0x90
[196669.996626]  entry_SYSCALL_64_after_hwframe+0x61/0xcb
[196669.996844] RIP: 0033:0x7ff2142ae5a4
[196669.996998] Code: 63 f6 48 8d 44 24 60 48 89 54 24 30 48 89 44 24 10 48 8d 44 24 20 48 89 44 24 18 b8 10 00 00 00 c7 44 24 08 10 00 00 00 0f 05 <48> 63 f8 e8 c4 fb fd ff 48 83 c4 58 c3 0f be 05 0a 03 04 00 c3 53
[196669.997774] RSP: 002b:00007fffe909f090 EFLAGS: 00000206 ORIG_RAX: 0000000000000010
[196669.998086] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007ff2142ae5a4
[196669.998382] RDX: 00007fffe909f0f0 RSI: 0000000000008914 RDI: 000000000000000d
[196669.998679] RBP: 00007ff213da1940 R08: 00007ff2142f1d90 R09: 0000000000000001
[196669.998968] R10: 0000000000000003 R11: 0000000000000206 R12: 000000000000000d
[196669.999258] R13: 00007fffe909f0f0 R14: 0000000000000001 R15: 0000000000000000
[196669.999549]  </TASK>
[196669.999645] ---[ end trace c36911eae91fc75c ]---
3

I have the exact same issues, albeit with a Banana Pi R3, so this is not specific to X86. The card is assigned an interface, but never gets put in an UP state.

It looks like it's an issue specific to OpenWRT itself, most likely in the hostapd implementation.

Others have had success with other linux distros, but it would be nice to have the OpenWRT Web GUI. Most likely need to wait a bit longer for support to mature in OpenWRT.

EDIT: I think the issue is that OpenWRT does not know how to handle 6Ghz cards. OP, what frequency is your card? I can get my 2.4Ghz and 5Ghz cards to work, but not 6Ghz. I was able to trick my 6Ghz card into coming up by installing the 5Ghz card, configuring that for AX and 160Mhz operating width, and then swapping back in the 6Ghz card. Still doesn't give a usable AP as OpenWRT is going to need to mature to add 6Ghz to the hostapd netifd and luci packages to catch up.

I think you'll be limited to a vanilla linux distro with bleeding edge packages if you want a fully functional 6Ghz Access Point.

4

I've got the specific 6Ghz model though I'm not against running it in 5Ghz mode (if that's...doable? I can't find much info on it either way)

I am curious if 6Ghz support is something that could be enabled for the full hostapd package. Especially with targets like the Pi or x86 where storage is measured in gigs instead of a handful of megabytes

5

If the hostapd package in the version of openwrt you are using has support for 6Ghz, you'll have to configure via command line and config files most likely. I'd recommend using snapshot to have the best shot at getting something usable.

6

I've been using the Snapshot builds since the drivers were apparently only backported to 5.15, though I'm not sure what settings Hostapd is built with on OpenWRT's side

I'm not sure what configuration changes would need to be applied manually to enable a 6Ghz capable card though, even just for 5Ghz operation

7

These cards are not band selectable typically. If your card is fused for 6ghz, that's all it'll be capable of.

You'll have to mess around with the hostapd config file using a text editor through ssh. Read the man pages for hostapd. There is no luci support for 6ghz. It may not even work editing the config file. Your best bet is bleeding edge Linux distro and learning the command line config.

8

I was able to get it to show up on 6Ghz only via hostapd under my NAS on Gentoo for testing, but OpenWRT is definitely preferable (and sadly the chip doesn't seem to play well with PCI-E passthru yet)

I'll have to see if I can replicate it across to OpenWRT's hostapd or not

9

I figured out how to get the 6Ghz band working on OpenWRT. Luci doesn't know what to do with 6ghz cards, so you have to manually edit /etc/config/wireless

nano /etc/config/wireless

Find your interface and add these two lines:

option channel 'auto'
option band '6g'

Now restart your network

/etc/init.d/network reload

10

Current OpenWrt (at least snapshots) should know about 6 GHz, at least it did work for me wit mt7921au (after setting the correct country code).

11

Yes you are right, I had an older snapshot installed and the attended-sysupgrade apparently didn't pull in the new luci packages. I reinstalled with the newest snapshot and it just worked after installing the kmod-ath11k-pci and ath11k-firmware-qcn9074 packages.

12

It's working on the latest snapshot builds?

Sounds like I have a project for the 3 day weekend!

13

What is working? 2.4, 5 or 6ghz version?