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 https://github.com/kvalo/ath10k-firmware/tree/master/QCA9984/hw1.0/220.127.116.11 -->
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: https://steamcommunity.com/discussions/forum/0/3118150513202463640/, 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...
Can you change your country to Panama from the wireless country setting? I am waiting for your reply.
Not at all a good idea (read actively illegal), even more so if there really is a radar near by.
From the OP's thread back in October...