I don't know if this helps prove or disprove (or neither) your thoughts there, but my setup is as follows and I am able to complete DHCP via a fully wireless mesh node on nss 11.4 / ath11k 2.12 (wired node is also running same build):
Ubiquiti GW (UXG-Max) -> AX3600 Wired AP -> AX3600 wireless mesh nodes
... \
.. Windows DHCP Server
i just checked a different client and it was able to pull an ip no problem.
maybe its an issue with this one device, its an (again...) esp32 based device so probably an incomplete network stack.
I've reset the router settings to default to see if the RX Rate will change.
And I get 160 MHz now.
Uploading the backup of the settings sets the rate back to 80 MHz.
I have flashed the build from @AgustinLorenzo with reset of the settings and this way I get 160 MHz too.
What do you think about the possible issue?
Will have to figure out what's wrong with my config.
I've tried to delete my wifi networks and then recreate them from scratch but that didn't help.
Maybe I'll have to start with the default settings or somehow the thermal throttling settings remained in my config somehow.
Interesting fact is that with all the latest commits (fixes) and FW 2.12 if I reset the settings to default the router cannot get IPv6 address via DHCP from my ISP. If I upload my settings backup file I get IPv6 but in LUCI I see only 80 MHz RX Rate.
Update - after more than 10 reflashes and resetting to default settings I'm really puzzled. Even with @AgustinLorenzo's build I cannot get 160 MHz RX.
Previously I've tried his build and it worked but now it doesn't.
What are the proper settings with FW 2.12 - I compiled with all the commits from wifi-2.12 branch (with disabled CONFIG_ATH11K_THERMAL) and flashed it not keeping my old settings but I get only 80 MHz RX rate.
A quick note for those who have been migrating their .config for some time:
I had pretty much every qca_nss-* module compiled in.
My .config was from way back when I was still running @bitthief build... Did not know back then and "hey, lets turn it all on!"...
I just removed 10+ useless (to me) qca_nss modules, along with the same number of qca_nss_drv options.
https://github.com/JuliusBairaktaris/Qualcommax_NSS_Builder/blob/main/ax3600.config is a great starting point.
Thanks @JuliusBairaktaris
You're welcome! Glad you like it. I try to keep up with @qosmio's development as much as possible. If anyone finds a redundant or missing module, please make a pull request.
New potential tweak anyone? 
edit : ive noticed you pushed a new 11.4 fw 2 days ago. this is most likely the fix not 2.12... although who knows.
just fiy, i made the upgrade to the 2.12 builds (all 3 301ws) today.
on both nss firm 11.4 and 12.5 my inactive time issue is now fixed.
prior to 2.12 it was fixed on 12.5 but broken on 11.4, but with 2.12 its fixed on 11.4 as well:
root@OPENWRT-PRIMARY:~# dmesg | grep '11.4\|2.12' ; iw dev phy1-ap1 station dump | grep 'boot\|inact' ;
[ 2.129269] aquantia_phy_api_ops_init[1485]:INFO:qca probe aquantia phy driver succeeded!
[ 17.915136] qca-nss 39000000.nss: NSS FW Version: NSS.HK.11.4.0.5-6-R
[ 19.449098] ath11k c000000.wifi: fw_version 0x2c0584a5 fw_build_timestamp 2024-07-11 16:11 fw_build_id WLAN.HK.2.12-01368-QCAHKSWPL_SILICONZ-1
[ 20.145982] ath11k c000000.wifi: fw_version 0x2c0584a5 fw_build_timestamp 2024-07-11 16:11 fw_build_id WLAN.HK.2.12-01368-QCAHKSWPL_SILICONZ-1
[ 24.217867] ECM database jhash random seed: 0x1164539a
[ 33.091164] br-lan: port 7(phy1-ap1) entered blocking state
inactive time: 15170 ms
associated at [boottime]: 33.541s
inactive time: 17170 ms
associated at [boottime]: 49.130s
inactive time: 970 ms
associated at [boottime]: 46.924s
inactive time: 16570 ms
associated at [boottime]: 46.928s
inactive time: 2970 ms
associated at [boottime]: 47.065s
inactive time: 370 ms
associated at [boottime]: 47.153s
inactive time: 1970 ms
associated at [boottime]: 47.227s
inactive time: 37970 ms
associated at [boottime]: 47.318s
inactive time: 37570 ms
associated at [boottime]: 47.319s
inactive time: 16670 ms
associated at [boottime]: 47.640s
inactive time: 37070 ms
associated at [boottime]: 47.642s
inactive time: 1670 ms
associated at [boottime]: 47.759s
inactive time: 13670 ms
associated at [boottime]: 48.645s
inactive time: 1470 ms
associated at [boottime]: 48.890s
inactive time: 16470 ms
associated at [boottime]: 50.086s
edit : also, who knows but i'm also getting slightly higher throughput sitting in the same location (couch). before i was getting about 170-175MB/s from my NAS. i am now getting 190-200MB/s.
hi! somewhere above you mentioned you had some other ath11k patches... primarily one(s) that improve roaming?
any chance i could give these a try?
i took a look at the dd-wrt svn / github mirror but was unable to find anything... same with the thermal patch so im guessing im just looking in the wrong place?
either way, thank you for the thermal patch.
i need to port this patch to the openwrt tree first and its a massive patch. so not just 2 lines. and i also have alot of other enhancements like ack timing support. but i'm willing to bring all these enhancements to openwrt as well in its original form. right now my internal source has a lot of code in it which might be related to nda material since the informations i often used for modifications are not public available. so cleanup work is required. i sended the termal patch direct to qosmio like others. so you are not looking at the wrong place. its just not yet there
I used to do it like you did because starting with NSS build for the first time was like exploring the jungle.
I made this some time ago following @qosmio recommendations. This is definitely the right way.
Still I want to add my observations from testing new FW 2.12.
@BrainSlayer please see the below info. Is there anything else I can do in order to help/test why I still see 80 MHz cap with my setup.
I still struggle with the 80 MHz RX Rate cap on my QNAP with FW 2.12.
Just a few moments ago I simply switched to performance governor and after a reboot I saw my Moto connected at 160 MHz RX Rate for a while and then it went to 80 MHz and it never switched back to 160.
Another observation with the new FW 2.12 is that most of the time my phone is close to the router but with older FW I see 2401.9 Mbit/s, 160 MHz, HE-MCS 11, HE-NSS 2 mostly, whereas with 2.12 I see lower rates on the same location. 
Iperf3 and Speedtest download test results are close. Upload is limited to 650 Mbps when it's capped at 80 MHz).
...you are flying pretty close to the sun now 
301w + 2.12 + 12.5 about 5m from AP, server is 1 hop down the LAN.
apart from the "values" you see in the gui. have you tried todo any bandwidth measurements? alot of things you see can be also just bogus since all the rate and bw management is handled by the firmware and not by the wireless stack. so you just see reported values, wherever they are generated. a guy who is in the openwrt maintainer team too just told me a month ago that 160 mhz is partitially broken in the hw itself on all 8074 chipsets which is the reason why qca removed 160 mhz support from the propertiery wifi drivers. i cannot verify this if broken or not. but this is a statement i got told. on my intel ax210 it seems to work
Hey everyone,
I hope I am not 'kicking a dead horse' with this question, but does any dev know if there is a chance to fix 160mhz support on nbg7815? I recall some attempts a while ago in this thread, but no success (as far I as know).
At the moment, if I try to set 160mhz on any of the radios, auto or fix channel, tried even few different countries - every time I am getting dfs error in the log and radio disables itself. Below is snippet from the log:
Mon Aug 5 13:54:15 2024 daemon.notice hostapd: phy0-ap0: ACS-COMPLETED freq=5640 channel=128
Mon Aug 5 13:54:15 2024 daemon.notice hostapd: phy0-ap0: interface state ACS->HT_SCAN
Mon Aug 5 13:54:16 2024 daemon.notice hostapd: phy0-ap0: interface state HT_SCAN->DFS
Mon Aug 5 13:54:16 2024 daemon.notice hostapd: phy0-ap0: DFS-CAC-START freq=5640 chan=128 sec_chan=-1, width=2, seg0=114, seg1=0, cac_time=600s
Mon Aug 5 13:54:16 2024 daemon.err hostapd: nl80211: kernel reports: (extension) channel is disabled
Mon Aug 5 13:54:16 2024 daemon.err hostapd: DFS start_dfs_cac() failed, -1
Mon Aug 5 13:54:16 2024 daemon.err hostapd: Interface initialization failed
Mon Aug 5 13:54:16 2024 daemon.notice hostapd: phy0-ap0: interface state DFS->DISABLED
Mon Aug 5 13:54:16 2024 daemon.notice hostapd: phy0-ap0: AP-DISABLED
Would anyone know if there is a chance to tackle this or should I just put my hopes away and live on 80mhz till the end of days 
160mhz was working fine on stock zyxel fw, and now I am using @asvio builds for a while now, which are amazing and rock solid. If only that 160mhz started working, I would have my router of dreams!
Cheers folks!
EDIT:
@BrainSlayer - I see you posted this while I was typing - what a coincidence! Should I understand that this may be one of the reason my nbg7815 woes?
I think that the problem may be with BDF files.
All of these routers are configured to use two separate 5GHz radios in 8x8 configuration:
This is not supported by ath11k driver.
There are also two models that have the 5GHz radios configured as low and high band:
Maybe you should try using the BDF files from these routers as a test and see if you can get 160MHz working.
the error says that 160 mhz is not supported by fw or regulatory db in your region in the specified frequency range. check iw reg get and iw phy phy0 channels and compare it with the selected frequency from your log. in addition you should check iw phy phy0 info if your device is 160 mhz capable at all
Thank you for your quick reply!
I have run these commands (I am quite a noob, so didn't know about them), below is the result:
root@OpenWrt:~# iw reg get
global
country 00: DFS-UNSET
(755 - 928 @ 2), (N/A, 20), (N/A), PASSIVE-SCAN
(2402 - 2472 @ 40), (N/A, 20), (N/A)
(2457 - 2482 @ 20), (N/A, 20), (N/A), AUTO-BW, PASSIVE-SCAN
(2474 - 2494 @ 20), (N/A, 20), (N/A), NO-OFDM, PASSIVE-SCAN
(5170 - 5250 @ 80), (N/A, 20), (N/A), AUTO-BW
(5250 - 5330 @ 80), (N/A, 20), (0 ms), DFS, AUTO-BW, PASSIVE-SCAN
(5490 - 5730 @ 160), (N/A, 20), (0 ms), DFS, PASSIVE-SCAN
(5735 - 5835 @ 80), (N/A, 20), (N/A), PASSIVE-SCAN
(57240 - 63720 @ 2160), (N/A, 0), (N/A)
phy#2 (self-managed)
country GB: DFS-ETSI
(2402 - 2482 @ 40), (N/A, 20), (N/A)
(5170 - 5250 @ 80), (N/A, 23), (N/A), NO-OUTDOOR, AUTO-BW
(5250 - 5330 @ 80), (N/A, 23), (0 ms), NO-OUTDOOR, DFS, AUTO-BW
(5490 - 5590 @ 80), (N/A, 30), (0 ms), DFS, AUTO-BW
(5590 - 5650 @ 40), (N/A, 30), (600000 ms), DFS, AUTO-BW
(5650 - 5710 @ 40), (N/A, 30), (0 ms), DFS, AUTO-BW
phy#1 (self-managed)
country GB: DFS-ETSI
(2402 - 2482 @ 40), (N/A, 20), (N/A)
(5170 - 5250 @ 80), (N/A, 23), (N/A), NO-OUTDOOR, AUTO-BW
(5250 - 5330 @ 80), (N/A, 23), (0 ms), NO-OUTDOOR, DFS, AUTO-BW
(5490 - 5590 @ 80), (N/A, 30), (0 ms), DFS, AUTO-BW
(5590 - 5650 @ 40), (N/A, 30), (600000 ms), DFS, AUTO-BW
(5650 - 5710 @ 40), (N/A, 30), (0 ms), DFS, AUTO-BW
phy#0 (self-managed)
country GB: DFS-ETSI
(2402 - 2482 @ 40), (N/A, 20), (N/A)
(5170 - 5250 @ 80), (N/A, 23), (N/A), NO-OUTDOOR, AUTO-BW
(5250 - 5330 @ 80), (N/A, 23), (0 ms), NO-OUTDOOR, DFS, AUTO-BW
(5490 - 5590 @ 80), (N/A, 30), (0 ms), DFS, AUTO-BW
(5590 - 5650 @ 40), (N/A, 30), (600000 ms), DFS, AUTO-BW
(5650 - 5710 @ 40), (N/A, 30), (0 ms), DFS, AUTO-BW
Radio 0:
root@OpenWrt:~# iw phy phy0 channels
Band 2:
* 5180 MHz [36]
Maximum TX power: 23.0 dBm
Channel widths: 20MHz HT40+ VHT80
* 5200 MHz [40]
Maximum TX power: 23.0 dBm
Channel widths: 20MHz HT40- HT40+ VHT80
* 5220 MHz [44]
Maximum TX power: 23.0 dBm
Channel widths: 20MHz HT40- HT40+ VHT80
* 5240 MHz [48]
Maximum TX power: 23.0 dBm
Channel widths: 20MHz HT40- HT40+ VHT80
* 5260 MHz [52]
Maximum TX power: 23.0 dBm
Radar detection
Channel widths: 20MHz HT40- HT40+ VHT80
DFS state: usable (for 14925 sec)
DFS CAC time: 60000 ms
* 5280 MHz [56]
Maximum TX power: 23.0 dBm
Radar detection
Channel widths: 20MHz HT40- HT40+ VHT80
DFS state: usable (for 14925 sec)
DFS CAC time: 60000 ms
* 5300 MHz [60]
Maximum TX power: 23.0 dBm
Radar detection
Channel widths: 20MHz HT40- HT40+ VHT80
DFS state: usable (for 14925 sec)
DFS CAC time: 60000 ms
* 5320 MHz [64]
Maximum TX power: 23.0 dBm
Radar detection
Channel widths: 20MHz HT40- VHT80
DFS state: usable (for 14925 sec)
DFS CAC time: 60000 ms
* 5500 MHz [100]
Maximum TX power: 30.0 dBm
Radar detection
Channel widths: 20MHz HT40+ VHT80
DFS state: usable (for 14925 sec)
DFS CAC time: 60000 ms
* 5520 MHz [104]
Maximum TX power: 30.0 dBm
Radar detection
Channel widths: 20MHz HT40- HT40+ VHT80
DFS state: usable (for 14925 sec)
DFS CAC time: 60000 ms
* 5540 MHz [108]
Maximum TX power: 30.0 dBm
Radar detection
Channel widths: 20MHz HT40- HT40+ VHT80
DFS state: usable (for 14925 sec)
DFS CAC time: 60000 ms
* 5560 MHz [112]
Maximum TX power: 30.0 dBm
Radar detection
Channel widths: 20MHz HT40- HT40+ VHT80
DFS state: usable (for 14925 sec)
DFS CAC time: 60000 ms
* 5580 MHz [116]
Maximum TX power: 30.0 dBm
Radar detection
Channel widths: 20MHz HT40- HT40+ VHT80
DFS state: usable (for 14925 sec)
DFS CAC time: 60000 ms
* 5600 MHz [120]
Maximum TX power: 30.0 dBm
Radar detection
Channel widths: 20MHz HT40- HT40+ VHT80
DFS state: usable (for 14925 sec)
DFS CAC time: 600000 ms
* 5620 MHz [124]
Maximum TX power: 30.0 dBm
Radar detection
Channel widths: 20MHz HT40- HT40+ VHT80
DFS state: usable (for 14925 sec)
DFS CAC time: 600000 ms
* 5640 MHz [128]
Maximum TX power: 30.0 dBm
Radar detection
Channel widths: 20MHz HT40- HT40+ VHT80
DFS state: usable (for 14925 sec)
DFS CAC time: 600000 ms
* 5660 MHz [132]
Maximum TX power: 30.0 dBm
Radar detection
Channel widths: 20MHz HT40- HT40+ VHT80
DFS state: usable (for 14925 sec)
DFS CAC time: 60000 ms
* 5680 MHz [136]
Maximum TX power: 30.0 dBm
Radar detection
Channel widths: 20MHz HT40- HT40+ VHT80
DFS state: usable (for 14925 sec)
DFS CAC time: 60000 ms
* 5700 MHz [140]
Maximum TX power: 30.0 dBm
Radar detection
Channel widths: 20MHz HT40- VHT80
DFS state: usable (for 14925 sec)
DFS CAC time: 60000 ms
* 5720 MHz [144] (disabled)
* 5745 MHz [149] (disabled)
* 5765 MHz [153] (disabled)
* 5785 MHz [157] (disabled)
* 5805 MHz [161] (disabled)
* 5825 MHz [165] (disabled)
* 5845 MHz [169] (disabled)
* 5865 MHz [173] (disabled)
* 5885 MHz [177] (disabled)
Radio 2:
root@OpenWrt:~# iw phy phy2 channels
Band 2:
* 5180 MHz [36]
Maximum TX power: 23.0 dBm
Channel widths: 20MHz HT40+ VHT80
* 5200 MHz [40]
Maximum TX power: 23.0 dBm
Channel widths: 20MHz HT40- HT40+ VHT80
* 5220 MHz [44]
Maximum TX power: 23.0 dBm
Channel widths: 20MHz HT40- HT40+ VHT80
* 5240 MHz [48]
Maximum TX power: 23.0 dBm
Channel widths: 20MHz HT40- HT40+ VHT80
* 5260 MHz [52]
Maximum TX power: 23.0 dBm
Radar detection
Channel widths: 20MHz HT40- HT40+ VHT80
DFS state: usable (for 15047 sec)
DFS CAC time: 60000 ms
* 5280 MHz [56]
Maximum TX power: 23.0 dBm
Radar detection
Channel widths: 20MHz HT40- HT40+ VHT80
DFS state: usable (for 15047 sec)
DFS CAC time: 60000 ms
* 5300 MHz [60]
Maximum TX power: 23.0 dBm
Radar detection
Channel widths: 20MHz HT40- HT40+ VHT80
DFS state: usable (for 15047 sec)
DFS CAC time: 60000 ms
* 5320 MHz [64]
Maximum TX power: 23.0 dBm
Radar detection
Channel widths: 20MHz HT40- VHT80
DFS state: usable (for 15047 sec)
DFS CAC time: 60000 ms
* 5500 MHz [100] (disabled)
* 5520 MHz [104] (disabled)
* 5540 MHz [108] (disabled)
* 5560 MHz [112] (disabled)
* 5580 MHz [116] (disabled)
* 5600 MHz [120] (disabled)
* 5620 MHz [124] (disabled)
* 5640 MHz [128] (disabled)
* 5660 MHz [132] (disabled)
* 5680 MHz [136] (disabled)
* 5700 MHz [140] (disabled)
* 5720 MHz [144] (disabled)
* 5745 MHz [149] (disabled)
* 5765 MHz [153] (disabled)
* 5785 MHz [157] (disabled)
* 5805 MHz [161] (disabled)
* 5825 MHz [165] (disabled)
* 5845 MHz [169] (disabled)
* 5865 MHz [173] (disabled)
* 5885 MHz [177] (disabled)
It indeed looks like zyxel used some magic sauce to get that 160mhz in their stock fw - unless I am reading it all wrong...
Could you please have a quick glance and confirm that there is no 160mhz support there?
Thank you.
Thank you - I never realised that.
I'd love to try, but with my limited experience I wouldn't even know where to start with changing those files
its no magic. the self managed regdb output just does not permit 160 mhz and its of course possible to override it and to use the linux regdb. basicly the regulatory code needs to be removed from the calibration data which is done for other device in openwrt as well, but usually not for yours. so a small modification in openwrt would usually fix your issue. check the file 11-ath11k-caldata for devices like mx4200 you will find a line named "ath11k_remove_regdomain". this is missing for nbg7815 and would fix that issue if i'm correct. right now the chipset uses its internal maybe outdated regulatory information which prevents you of using 160mhz
who said its not supported to run 2 devices with 8x8. this isnt true. nothing in the driver prevents that. the only limitation is chain signal reporting which is limited to 4x4. but signal chain reporting is broken anyway in the standard ath11k. but this is only for reporting and has no functional effect. i fixed this in my firmware but it requires also a kernel hack which would never be accepted upstream.
Here is some info: Adding OpenWrt Support for Netgear RAX120 (Nighthawk AX12) - #188 by kirdes
And I think @robimarko mentioned it.