Build for Netgear R7800

This is actually interesting

CPU1 min frequency also has to be increased because there is a hardware constraint
	# kraits cannot operate at 384MHz when L2 is at 1GHz.

This appears to be coming full circle back to something like the startup script I commented out because people in this thread said it was outdated. I am just going to go ahead and uncomment it again in my 19.07 hnyman firmware.

echo ondemand > /sys/devices/system/cpu/cpufreq/policy0/scaling_governor
echo ondemand > /sys/devices/system/cpu/cpufreq/policy1/scaling_governor
echo 800000 > /sys/devices/system/cpu/cpufreq/policy0/scaling_min_freq
echo 800000 > /sys/devices/system/cpu/cpufreq/policy1/scaling_min_freq
echo 75 > /sys/devices/system/cpu/cpufreq/ondemand/up_threshold
echo 10 > /sys/devices/system/cpu/cpufreq/ondemand/sampling_down_factor
1 Like

please can someone give me step by step instructions/ a video on how to install hnyman build using the tftp method. I have been reading and I still don't get how to install the .img on to my r7800

Download a *-factory.img image and then install it following this guide
(tftp client needs to be enabled in the Programs and Features menu in windows).

I clicked this guide but your link took me to and then it redirected to

You should be able to flash directly from the Netgear GUI.

The TFTP flashing mode should not be needed, but in case you later need it, it is well documented in wiki and here in the forum:

1 Like

Dear mat432111,
Hello and I hope that you are both safe and well. In order to flash to OpenWRT and back to R7800 stock easily - just follow these steps below Step 1 comes after Step 3 for obvious reasons :
Download all needed firmware and application ( s ) before beginning

1 - Set static ip address on your computer - I use Windows - see below
To set a static IP address in Windows 7, 8, and 10 Set the following address below :

Select Use the following IP address and set 
the IP address information like below:

IP address =>
Subnet mask =>
Default Gateway =>

2 - Download and save the router’s firmware into a folder on the desktop of your computer.
3 - Download latest Tftpd64 ( v4.64 28th Feb 2019 ) - I use the portable version from here Tftpd64
4 - Then follow the instructions from this page : How to upload firmware to a NETGEAR router using TFTP client
5 - As I said this works with both OpenWRT factory images and NETGEAR OEM Firmware - and never sysupgrade .bin files - these are flashed via Luci while running OpenWRT.
6 - Latest NETGEAR OEM R7800 Firmware download is here : R7800 — Nighthawk X4S AC2600 Firmware Version
That's about it and I hope this helps
Peace and Stay Well

Video Gives You An Example Here : TP Link Restore to OEM Factory Firmware

Even though this video uses a TP Link Router the process also works with NETGEAR R7800

1 Like

Interesting, I'd like that to be the case so I've decided to try that. Updated driver with updated firmware that leads to a stable situation :grin:

I've flashed stable owrt2102-r15934 today, as an "upgrade" from stable owrt1907-r11285. That latter one was my first encounter with -ct stuff. I have since experienced lags on iOS devices and occasional dropouts on rMBP too. And just today and yesterday an unresponsive R7800. That motivated me to flash the latest and greatest stable owrt2102-r15934 but also read up on the -ct stuff and iOS devices not being as "stable" compared to the old mainline driver.

I have mostly iOS devices, so after reading your comments I downloaded the most recent firmware from kvalo's repository and copied that to /lib/firmware/ath10k/QCA9984/hw1.0/firmware-5.bin and rebooted. I'm going to try this combination to see how that rolls.

So far, your owrt2102-r15934 build is looking great @hnyman ; just a shoutout and a thank you for your work :heart: :+1:

FWIW, I'm discovering that the -ct driver now seems to cause trouble with the latest hostapd/mac80211 version in the 21.02 branch, as documented here:

I took all -ct out of my R7800, my current setup is mainline driver (provided by hnyman's builds as an additional download) + mainline 10.4- firmware. Seems to be stable. In the past the -ct driver didn't make a difference to me, but it now does with a Mac.

FWIW, I also have 2 UniFi Lite APs running OpenWRT and on those -ct is trouble too, I run them with mainline driver + firmware and they work fine like that.

I really want to get to a stable setup and not touch it for a long time. I was hoping the stable 21.02 would be it so I can stay on that until I retire the hardware.



DSA has been dropped from the kernel 5.10 PR, so this kernel 5.10 test build is made with the traditional swconfig switch control/driver. Normal network settings work in sysupgrade from 5.4.

It's been two days since I flashed owrt2102-r15934 and only replaced the most recent firmware from kvalo's repository. I kept the -ct driver. My iOS-devices responded better with that combo. Just a half hour ago, my Mac had a connection issue. So I went ahead and did the same; install the mainline driver too, to replace the -ct driver. And because "things need to be correct" I overshot and also replaced the -ct firmware package with the mainline package, although I manually replaced that already. I only did that because I might not remember in a year what I did exactly; mix and match driver/firmware. Once I replaced the -ct firmware package with the mainline firmware package, I manually replaced the firmware-5.bin file again.

This replacing has been made a lot easier thanks to hnyman providing the mainline driver as an additional download. :+1:

1 Like

I was experiencing the same problems too with a Mac, it would disconnect and not re-connect on its own, the router would disconnect it after 2 seconds for "inactivity". It's what prompted me to try the mainline driver. So far so good, but also a bit early to tell. There's also this 3.10-00047 firmware that I had good success with in the past, though not sure it's that different from which seems to still get updates.

And indeed, thank you @hnyman for being receptive to my suggestion and providing the mainline driver as a separate ipk, it really helps those of us with -ct problems.


@hnyman thanks for the great work on this firmware. I just installed it on my R7800.

I found a problem on the latest image downloaded today for 19.07 - IPv6 for LAN wasn't working at all.

When I did cat /etc/config/dhcp the "wan6" interface configs did not exist. I was trying to enable IPv6 relay to work.

I had to manually edit the /etc/config/dhcp config and add this missing data:

config dhcp 'wan6'
        option interface 'wan6'
        option ra 'relay'
        option ndp 'relay'
        option start '100'
        option leasetime '12h'
        option limit '150'

Then after that from another post IPv6 working on router but not on clients - #11 by ctrt

uci set dhcp.wan6.master="1"
uci set dhcp.wan6.dhcpv6="relay"
uci commit dhcp
/etc/init.d/odhcpd restart
/etc/init.d/network restart

Then magically my IPv6 is now working and IPv6 relay also works. This must be a bug?

1 Like

I'm still running on owrt2102-r15934 and I believe this release with the mainline driver and firmware I'm using is not as stable as I hoped it to be... I think I'm having spontaneous reboots after a while. I need to dig in further, but me and my partner are both working from home. So I'm more inclined to get it stable than to get to the bottom of this. Uptime is 6 minutes, the reboot happens before the cache in Spotify times out. I'm going to flash a different build in my R7800, this current build is not stable enough for me... Sadly...

I'm logging the system log to my NAS, it's currently set to notice. Would setting it to informational or debug lead to a clue as to why my R7800 with this build spontaneously reboots? Or would a higher level just fill up disk space on my NAS more quickly? I haven't had the need to investigate "unstable" situations before so I'm unexperienced on that on OpenWRT, so sorry for asking a perhaps obvious question but I need this to be stable and I'm short on time as to when I can fool around during the day/evening without bothering a family member :grin:

It has been my experience that 19.07 hnyman-stable works well with non-ct driver and firmware blob (with the appropriate blob being installed via Luci software UI, not manual download+CLI). I have 3 R7800 routers running it just fine.

However, using a newer, manually downloaded blob from "master" with above setup, made WiFi go FUBAR.

It has also been my experience that 21.x hnyman-stable DOES NOT work with non-ct driver (supplied for 21.x) and firmware blob installed using the same method as above (getting blob via Luci). Maybe it will work if I got the latest blob for "master" and installed manually, but somehow I doubt it.

The truth may be that the non-ct driver and firmware just aren't properly tested past 19.x.

1 Like


I think I'm having spontaneous reboots after a while. I need to dig in further, but me and my partner are both working from home. So I'm more inclined to get it stable than to get to the bottom of this.

Haven't been active here for almost 2 years or more, I'm still using OpenWrt 18.06-SNAPSHOT, r8000-ad01cb514d it works as rocks solid, I don't think 18.06.x builds from @hnyman are available anymore, but you can manually compile it if you like via git or just use ath10k on 19.07.x branch.

Regarding wifi:

It's actually firmware-5.bin 10.4- from
It's little bit outdated, but seems very stable.

To replace both these files on your current firmware you need to go to:

cd /lib/firmware/ath10k/QCA9984/hw1.0
# backup original first
mkdir original
mv firmware-6.bin firmware-5.bin board-2.bin original/

# get the new firmware from linux-firmware
ln -s firmware-5.bin firmware-6.bin

The only thing that bothers me in this old firmware (from time to time) is the ipsec: it seems to reboot the router suddenly sometimes, it happens rarely though, but I might try new 19.07 branch with wireguard instead of ipsec to see if it's any good.

It seems though there is a lot of hassle with this new wifi driver ath10k-ct, I'm wondering why it's the default now, is there any info regarding that?


I still have a build from hnyman which is a snapshot of somewhere late in 2018, before the -ct drivers and firmware became the default in OpenWRT. That build from hnyman is rock solid indeed. Fast, stable. I decided to upgrade a few weeks ago for security reasons to a stable release (19.07.5 service release). I assumed the -ct stuff would have matured more so didn’t change anything. I did however experience lag on iOS devices.

I’ve found other posts questioning the decision by the devs to make the -ct stuff the default for ath10k and I understand the arguments in favor and opposed to that switch. The discussion about that move should not be made here. Here we discuss and appreciate hnyman’s efforts. I’ve used his builds a long time on my WNDR3700v2 and because of his open involvement here, I decided to buy a R7800 because he kept continuing releasing these great builds; download; flash; reboot; and keep on enjoying.

For the moment I'm running on the stable owrt19.07.7 build from hnyman with the mainline ath10k firmware and driver. I have removed the -ct driver and firmware. And to be complete, I've again copied the most recent firmware from kvalo's GitHub repo. It's been recently updated. We don't know what has been changed, but since it's not a new branch I'm going to assume it are bug fixes to make a seemingly more stable firmware than -ct more stable...

1 Like

The last couple of times I tested the non ct firmware I had lots of issues with it. Hangs, wifi speed reduction drops. CT however works absolutely fine in my setup I usually have around 10 wifi devices connected at the same time and about 20 different devices in total that connect during the day.
And it is heavily used right now since we are all working from home.

I might give the non ct another try and see if things have changed, usually non ct has the problem, that the firmware isn't aligned with the wireless driver development, which causes the issues we have seen quite a few times. Of course you will always find a few people that have issues, but if ct would have some many issues the forum would be full of reports and I only see a handful success stories with non ct. Most likely this is due to interoperability issues with a certain client chipset driver.

For the next build, I'll bump linux firmware, thus my repo will hold latest non-ct firmware, since 19.07 ships linux firmware which includes non-ct from April 2019.


I just uploaded build with non ct driver and firmware as default, we will see how it goes.


Please take the discussion about your build to somewhere else from this thread about my build...