Most stable build of OpenWrt for the Zyxel NBG6817 Armor Z2?

Hi all,

I really need some help. On all the builds of OpenWRT I've tried on this router, I've had nothing but trouble with the ath10k driver failing and crashing on high bandwidth downloads, like when apps update or games download on steam. It consistently crashes and requires the interface be restarted. The only solution this forum has really been able to provide is to change the channels away from DFS or switch between the CT and non-CT variant of the driver. Neither solution has worked for me and I'm beginning to pull my hair out... lol

I've seen that this has been reported multiple times by other users, but I have to assume there have been builds where this router worked, that I just haven't tried yet. So PLEASE... I'm begging you if you have this router or know how to aid in this, tell me me what the most stable build is in this regard.

I recently decided to try out the stock build again and the stability and thruput kind of blew me away. I didn't even know the router could perform that well because I immediately switched to OpenWRT after setup. It is however, lacking in what in all the amazing granule features OpenWRT provides.

So I ask again, please help.

which versions/builds would that be, precisely ?

I don't have the device, but the slightly other Archer C2600s, for me the most stable version
is 19.07.3, haven't tried 21.02 at all, yet.
But then again, my most bandwidth hungry devices all have wired connections.


I made the purchase on Jul 8, 2021, so from what I can deduce I started on the latest stable OpenWRT build available at the time which was 19.07.7. I believe that ran okay at first though I was still getting acclimated to the router. I then updated to 19.07.8 which released in August, which is when I think I started seeing this issue prominently. I'm not sure if it was present before though, every update after to 21.02 has not solved the issue. I've also tried all of ACWifidude's builds to no avail.

I will definitely try out 19.07.3

I am very surprised that you are having problems with openwrt on this device. As far as I know, there are a lot of people who support this hardware. And I know that it is one of the most stable devices. I also use openwrt with Unifi HD with the same hardware. It works fine in version 21.02. I am using non CT drivers. I did not make any other settings. I can get 500 mbps speed with 80mhz Intel AX200.

I'm really at a loss tbh. This only happens under high bandwidth loads on the 5ghz radio. The only thing I can think is that DFS is getting triggered regardless of what channel I'm on.

I was watching this video and I too happen to live not too far from a national airport.

Actually, it appears I spoke too soon.

It seems the stock firmware is ALSO suffering from the issue I'm facing, so this appears to not be a build version issue at all.

I'm at a loss.

What do the logs say?

What would be good is to connect via serial and capture the kernel log up until the crash and reboot.

That should give an idea of what is falling over.

If it’s occurring in v19, v21 and stock you may have a faulty component.

Here's the snippet of what I saved previously. I'll either have to reflash OpenWRT to grab more or figure out how to get logs through SSH. Unfortunately I haven't learned how to do any more debugging like you suggested with the serial cable.

[ 4765.797273] br-lan: port 2(5G) entered disabled state 
[ 4765.910213] ath10k_pci 0000:01:00.0: mac flush null vif, drop 0 queues 0xffff 
[ 4765.910834] 5G: Destroyed NSS virtual interface 
[ 4765.916771] ath10k_pci 0000:01:00.0: peer-unmap-event: unknown peer id 0 
[ 4765.920740] ath10k_pci 0000:01:00.0: peer-unmap-event: unknown peer id 0 
[ 4772.315581] ath10k_pci 0000:01:00.0: 10.4 wmi init: vdevs: 16 peers: 48 tid: 96 
[ 4772.315612] ath10k_pci 0000:01:00.0: msdu-desc: 2500 skid: 32 
[ 4772.396143] ath10k_pci 0000:01:00.0: wmi print 'P 48/48 V 16 K 144 PH 176 T 186 msdu-desc: 2500 sw-crypt: 0 ct-sta: 0' 
[ 4772.396959] ath10k_pci 0000:01:00.0: wmi print 'free: 84920 iram: 13156 sram: 11224' 
[ 4772.816358] ath10k_pci 0000:01:00.0: rts threshold -1 
[ 4772.817005] ath10k_pci 0000:01:00.0: Firmware lacks feature flag indicating a retry limit of > 2 is OK, requested limit: 4

I've also posted more logs trying to tackle this obstacle before here:

There’s no crashes or reboots in those logs so nothing to go on.

Without capturing the actual crash via serial you will just be guessing.

Are you doing anything complex such as vlans or multiple ssids? Or running additional software on the router? Vpns, samba, asterix etc could make it fall over under load.

Do you know of any good resources or tutorials on putting this together. I can definitely solder a few pins to the board and make a cable if there's a guide for me to follow.

Yes, I did have some vlans, as well as adblock and SQM going, however I've tried disabling all of these to no avail. This aside, the issue persists on the stock firmware, so I'm willing to consider these not a part of the problem.

After some further testing today, I was able to find that channels 36-48 at 20hz is the only range where the driver didn't fully crash on high bandwidth downloads, 36 being the most stable. It did however cut out, and immediately come back on frequently.

There's a radar tower not more than 5 blocks away from my apartment at the airport. I honestly do think this is probably some crazy stuff happening due to DFS that most people don't run into because they aren't near one. Still, I think DFS is not working properly at all if this is the case.

Getting serial access is straightforward.

Purchase a usb to uart / ttl serial adapter, crack the router open and find the serial header. Attach leads from the usb to uart to the tx rx and ground. Power your router up.

Then watch the console till login prompt appears.

Adapter should be 3.3v or switchable 3.3 / 5v. Don’t connect vcc under any circumstances.

If there’s no header on the board to connect to you don’t have to solder one, holding pins on with a clothes peg is fine, or I’ve used alligator clips with electrical tape one the other side of the board.


Cable comes in Friday.


If it also happens with the OEM firmware, and if you're still under warranty, I'd suggest to look into the warranty options first (flash the OEM firmware twice and your device is back to vendor standards), as time might be running out.

You can also try an updated (QCA 'ath10k' wireless chipset-) firmware from --> /lib/firmware/ath10k/QCA9984/hw1.0/firmware-5.bin.

Given your environment you described in this thread, there may not be much else you can do with that device...except used a wired connection for high-bandwidth downloads.

Can this be done through SSH, or would I have to learn how to compile OpenWRT myself in order to accomplish this?

You can do that via ssh, just replace the existing file with the downloaded one (make sure to download it properly, not the HTML representation of github's webinterface - or just clone the git repo and copy it from there via scp).

First, thank you so much to everyone who has responded and tried to help me diagnose this issue. I FINALLY tracked down the culprit, and it was none of the above items already discussed.

According to this thread:, someone suggested disabling IPv6 in the client wireless interface.

And this worked. Seriously this worked. I have no more crashes and I'm downloading at 29mb/s. Which leads me to my next conundrum, though not as pressing. Is my router configured correctly for IPv6?

I haven't done any IPv6 related configuration.

IPv6 works reliably on OpenWrt and the nbg6817.

I believe you, and I jumped the gun. I managed to download at 25gbs at nearly 30mb/s before the interface crashed again.

I'm going to go take a walk...