Ipq806x NSS build (Netgear R7800 / TP-Link C2600 / Linksys EA8500)

Take a look at your regulatory settings and first see what the acceptable range is.

root@OpenWrt:~# iw reg get
country US: DFS-FCC
        (2400 - 2472 @ 40), (N/A, 30), (N/A)
        (5150 - 5250 @ 80), (N/A, 23), (N/A), AUTO-BW
        (5250 - 5350 @ 80), (N/A, 23), (0 ms), DFS, AUTO-BW
        (5470 - 5730 @ 160), (N/A, 23), (0 ms), DFS
        (5730 - 5850 @ 80), (N/A, 30), (N/A)
        (57240 - 71000 @ 2160), (N/A, 40), (N/A)

In the US to get 160mhz - set the channel to 100, wait a couple minutes for the router to make sure there is no RFS (radar interference) and you should be good to go.

Am in the US - had that set - it never came up. am not on CT driver, on the old. is there an issue there ?

Both drivers should work now (but not always with every client).

Two reasons most likely reasons it won’t work is either -

  1. the drivers don’t like the 160mhz client or
  2. Your router is picking up radar and is not allowing 160mhz.

Try the -ct drivers and see if you see a difference.

is there anyone out there that can run some tests on the htb+fq_codel offload in this chip?

NSS fq codel is quite potent - getting near line rate with latency similar to fq codel. Anything in particular you want to see on the test?

Two tests: line rate with a packet cap (if possible), fq_codel on and off.

With a tbf 200mbit. I asked kong over here to take a look, as I lack hardware (I actually do have this hardware in my storage unit), some more details about the test here: CeroWrt II - would anyone care? - #36 by KONG

I'm happy to hear you think it's good, but I've been worrying about the codel implementation in the 500-900mbit range. I think they implemented the wrong drop scheduler.

I suppose this ath10k fix didn't make it into the 21.x build from October 30th?

Correct, but that fix isn't needed for the 21.x branch in the first place, as the faulty mac80211 implementation was only recently backported to the master branch (21.x was branched off many months ago).

The bug on OpenWrt master was discussed at

References (from upstream Linux):

Edit: I'm referring to the OpenWrt master and 21.x branches, not the one from ACwifidude, but I guess he would not have performed the mac80211 backport himself as I'd guess it's not strictly specific to NSS.

1 Like

that I turn on the pc that I have connected by cable, and it takes about 30 seconds for the internet to be available, is a negative thing. Does anyone else happen to him? what cause is possible? I have proven the problem that it is from the r7800. Thank you!

hi, @ACwifidude can You add support for Trendnet TEW-827DRU v1.0R for You custom image? Thanks

Is it supported by 21.02? If you can help me get the right .dts settings we could always give it a try.

@xeonpj haven’t noticed any lag with wired connections. Try setting it to a static IP and see if that helps. I’ve had devices go bad before and perform weirdly with DHCP but still work fine with static.

Use static IP.

On oem's or voxtel's firmware . Connection laptop (wifi intel ax200 160Mhz) <-> r7800 <-> (ethernet) NAS allows you to get 940 Mbit/s in both directions. This isn't the limit.
When I used the wan port as the second interface to the local network, I got 1.3 Gbps (I downloaded the file from nas to smb3 share).

For the r7800, the speed of a large gigabit over wifi is a normal situation.
When I installed the stock openwrt 21.02.1 with the Ath10k-ct driver, I got 400 Mbps (in) and 600Mbps (out). With the Ath10k driver, the speeds are lower.
With your build (Ath10k-ct + OpenWrt 21.02 (Stable) + NSS Hardware Offloading). I got 637 Mbps (int) and 940 Mbps (out) . With driver Ath10k, the speed in both directions drops by about 1.5 times.

Is it possible to get speeds comparable to oem / voxel firmware? Or near gigabit to receive?


It's not even supported in OpenWrt

not officialy, take a look here Unofficial TRENDnet AC2600 (TEW-827DRU v1.0R)

Speeds look right. Wish our expert developers had access to all the code. There are still bits that are proprietary and hold us back from the full potential. If you find anything to make open source performance better or have the skills to make master (kernel 5.10) compatible with NSS again I’d love to improve the performance further.


thanks for the information. I also don't have the necessary skills.

Anybody having dns issues?
I'm having the strangest problems recently after updating to the most recent version of this build last week. Basically, after a day or so everything grinds to a halt.

Running a dslreports speedtest results in this...

timeout doing a trial download error:8
The browser failed on a trial download (10kb) from the closest (by ping) speed test server. The speed test does not continue in this case.

Since the nearest server was already located successfully, failing to download a small test chunk of data is unexpected.

But going directly to my ISP's speedtest results in this.

It's SUPER weird.
Another strange thing is clients on 802.11n connect to the network but don't get internet access unless I join them to the network with a static address.

I tried doing a full factory reset from Luci but after setting things up again I'm seeing the same behavior. Should I try the hard reset button? Does it do anything different than the Luci reset button?

Normally I can figure things out on my own but this has me very confused. Thanks for any ideas/help.

I have had problems with that, I do not know the solution, the static IP solves for a while and fails again.

Hmm. I’ve added some dynamic dns packages the last couple builds - I’d check to make sure dynamic dns is turned off if you don’t use it. Everything else is the same so it’ll take more troubleshooting. Let me know if that helps.