Build for Netgear R7800

I have built a nice build for Netgear R7800 that offers the basic router functionality plus some useful add-ons, but does not contain too much additional fancy stuff like multimedia.

The build is based on the bleeding-edge development main/master branch and the stable 23.05 branch. ("master" has been renamed as "main" in OpenWrt)

Current version:

Branch Version (branch-revision-commithash-date)
main/master (development branch) main-r26714-6fdf3a32d9-20240619 (DSA)
stable openwrt-23.05 owrt2305-r23902-50148a40d2-20240619 (swconfig, no DSA)

All builds are with the default ath10k-ct wifi driver. The mainline ath10k wifi driver is being offered as a downloadable .ipk in the download directory of each build.

R7800 firmware downloads are available in Dropbox:
Download site:

I only upload the versions after successfully flashing my own router, so the build has at least that much quality assurance process.

Full configuration and source code diffs are included in the download directory, in case somebody wants to utilize info in own builds. There is also a script to automatically re-create my build environment with all the sources patched with my patches. (advice in the next message)

Features included:

  • LuCI with HTTPS SSL support
    • LuCI statistics include CPU frequency scaling graph and CPU temp graph
    • Luci theme "openwrt-2020" included in addition to the default "bootstrap"
  • USB storage automounting
    • Support for various file systems to enable most drives.
      ext2/3/4, FAT, HFS+, CIFS/SMB, NTFS, EFI/GUID partitions
  • WiFi, WPS and reset buttons work
  • console tools: Nano text editor, htop, patch, ccrypt for file encryption/decryption
  • failsafe entrance trigger time window increased to 5 sec (from 2 s)
  • irqbalance for balancing irq load between CPU cores. Initially disabled in config.
    • see "cat /proc/interrupts" for summary of irq usage of CPU cores

Network tools

  • SQM-scripts for QoS traffic control. The package is initially disabled, as max speed needs to be adjusted to WAN connection speed
  • Adblock package (initially disabled)
  • IPv6: tunnel support for 6in4, 6to4, 6rd, IPv6 NAT support
  • unetd - new OpenWrt specific small VPN (in master)
  • wireguard VPN support (in master, 22.03)
  • kmod-tun, enables opkg install of OpenVPN (openvpn-openssl variant)
  • DDNS support
  • miniupnpd settings: leave upnp off by default in /etc/config/upnp
  • IEFT BCP38 support
  • wget, curl
  • iptables-mod-ipsec and kmod-ipt-ipsec

Noteworthy recent changes:

  • February 2020: wireguard added
  • March 2021: CPU frequency scaling settings configurable via /etc/init.d/cpufreq, applied at boot
  • Jan 2022: ramoops pstore support added.
    See /sys/fs/pstore/dmesg-ramoops-* files for a crash log after a reboot.
  • Sep 2022: unetd - new OpenWrt specific small VPN
  • Dec 2022: NTFS support in master from kmod-fs-ntfs3 in Linux 5.15
  • Dec 2022: Add openssh-sftp server, so that newest scp works without -O option

Note: As I build with standard kernel options, the release and snapshot packages should be compatible with my builds, in case somebody wishes to add packages to my build. That goes for "userspace" packages. Installing kernel package is more difficult and risky.


Instructions for re-creating my build environment

My firmware release contains also a script to re-create my full build environment in a few minutes. I use Ubuntu as my buildhost, so the prerequisites etc. are tailored for that.

The creation script runs pretty automatically. The needed few steps are:

  • Create the base directory (I use /Openwrt) and make it writable by your normal user account (non-root)
  • Download from my newest firmware the file and the three/four *.patch files to /Openwrt
  • Run It creates the complete build environment and applies the patches
  • Build firmware with hnscripts/

Detailed explanation of the steps in the build environment creation process :

  1. Create the base directory (like e.g. /Openwrt) to your buildhost. chown/chmod that directory to be writable by your normal user account (chmod 755). Buildroot will be created in that directory, e.g./Openwrt/master or /Openwrt/owrt2305

  2. Download the "" file from my newest firmware build package to /Openwrt and chmod "" to be executable

  3. Download the firmware's three/four patch files: -main.patch (or -openwrt.patch), -packages.patch, -luci.patch (and -routing.patch) to /Openwrt. Note that the master build environment needs the master patches, and correspondingly the openwrt-23.05 environment needs the openwrt-23.05 patches.

  4. Verify that "" references the correct patches: Check that the FILESTAMP variable definition matches the timestamp in actual patch names.

  5. Run "". It installs the needed prerequisite packages to Ubuntu, creates trunk or chaos git repository and downloads the feeds' sources, patches them and also adds the new files to version control as well as chmods the known script files to be executable.

    • If patch names are correctly set in"", all sources will get patched by the script. Main source needs to be patched first, as that patch possibly contains changes to feeds.conf.defaults. Then it updates the feeds (packages, luci, routing), patches the feed files and finally installs the packages from feeds with "scripts/feeds install -a".
    • Check the attributes of the possible script files added by the patches and chmod them executable, if needed. e.g. /etc/ and other scripts in /etc
      Note: With the current button hotplug procd functionality also the button scripts in /etc/rc.button need to be executable. (E.g. files/etc/rc.button/BTN_2)
    • Verify that the build script files located in /hnscripts are executable and have been added to git version control.
    • Verify that the new files have been added to git tracking. The script has commands for the "files" directory & ".config.init", but you should check if there are other unknown files added by the patches. The script tries to automatically include the noticed new files created by the patches.
  6. Copy possibly needed additional files and prepare the build system:

    • Download and extract llvm toolchain tar.gz for qosify building
    • Copy extra custom files to /files . E.g. your personal settings to be the included in the firmware.
    • Copy build keys to if you want to maintain the same build key in the new environment
    • Possibly also create a file share for transferring files. For example, I need /media/windows-share to easily move files from Virtualbox to PC.
    • Additionally, I need to set git options (username etc.) and to set minor OS options like gedit not producing backup files etc.

Steps 1-5 should be done automatically by the script, but verify the results :wink:

After this you should have an identical build environment as I have. I have actually recreated my current build environment several times with this process.

Note: The -main.patch also contains the device profile recipe ".config.init" with all the needed package selections and all build scripts used in my build environment.

Steps in the actual firmware build process in /Openwrt/master:

  1. cd into /Openwrt/master
  2. Copy .config.init as the new .config to initialize the build profile:
    cp .config.init .config
    ("make defconfig" will expand the recipe to a full .config . You can run that command also manually.)
  3. Do the actual make: hnscripts/
  4. transfer files from bin/target/ipq806x to wherever you need them. I use a script: hnscripts/

Explanation of the scripts in /hnscripts:

  • is the main build script that updates sources and builds the firmware
  • is the script that I use to copy firmware files to my PC
  • is the build environment creation script
  • Other scripts (timestampVersion, parallelcompile, singlecompile, kernelcompile, copypackages2tmp) are just helpers. creates the firmware release package with docs & patches and is automatically called at the end of a build. (Usually there is no need to call that manually.)

Reserved for future use


Did you try HZ=1000 instead of the default? When do you actually need to use nathelper-rtsp nowdays?

1 Like

I tried HZ=250 and did not see any difference compared to the default 100. But I did not test 1000 Hz, as I don't quite see how the timer interrupts would affect packet-driven QoS. As discussed in the SQM development forum, it looks the culprit is HTB qdisc which seems to dislike the dual-core with arm-cortex.

I am not using nathelper-rtsp myself, but I was asked to add that to my WNDR3700 build earlier and I have kept it in the recipe. It is so difficult to add kmods afterwards to private builds, so I have just kept it along in case somebody needs it.

"Software Rate Limiting

Use of HTB to rate limit connections to a given speed is to be preferred, as HTB buffers up one, and only one packet. Note that HTB is timer based; default Linux kernels are often compiled with HZ=250 (or even lower), causing burstyness and non-uniform delivery of packets; building your kernels at HZ=1000 will reduce this effect. Very important also is that your kernel have support for hi resolution timers (hpet or better)."

This is also recommended on BSD's, FWIW

1 Like

Thanks for digging that up. That sounds rather clear.

I tested with 1000HZ kernel and it has no significant impact, although there may be a marginal improvement. With 90/8 limits I get 85/7.6 with cake and 80/7.8 with simple, so the gap remains quite large. That is roughly the same that I got with the normal 100HZ after the first HTB performance patch. There are quite a lot of HTB performance patches in kernel 4.8, so I guess that I have to live with this until kernel 4.8 gets here.

Since you have a rather fast connection I don't think you'll see much of a difference, it's more crucial on slow DSL/Cable connections. I haven't done any real measurements but as far as perception goes I'd say that connections appears to be more consistent in terms of speed.

I will note that this advice is from May 2014 - 2 1/2 years ago. I know that a lot has changed in this time: but haven't followed it carefully enough to know whether it would make a difference.

I have posted a note on the Bloat mailing list to ask if it's still relevant.

See response at:

I uploaded a new build that has an older version of the "upstream thermal driver" adapted to ipq8065. It is still work in progress, but seems to work. More discussion about that thermal statistics driver at Supporting thermal sensors on ipq806x

the thermal driver got successfully backported from upstream Linux 4.9 and the PR 533 has been updated with it, but the PR 533 has not yet got pulled in. My build includes now the commits from PR533

PR533 has been accepted and the source code is included in the main LEDE repo.

Nothing build-specific, but nice to see that the router properly adjusted for the leap second :wink:

[91901.925431] Clock: inserting leap second 23:59:60 UTC

Note: the newest version lede-r2750-18152e71d8-20170104-musl1116 has been compiled with musl clib 1.1.16 that is not yet the default (and not yet used by the buildbot). So, no add-on packages can be installed to lede-r2750-18152e71d8-20170104-musl1116

I love your builds I am using them for my wndr3700 and wndr3800.
I have just ordered new device. Zyxel NBG6817, do you think you could include it to your builds? It seems to be the same hardware just eMMC flash different which is 4gb on Zyxel.

Sorry but no. I only build for devices that I have, so that I can test the builds.

1 Like

I understand. I was building long time ago on Openwrt and Then there was Arokh and you (actually arokh was before me). so I quit building my builds :smiley:
but seems like I will have to start building myself again :slight_smile:

If you like my build, you can easily copy my config and build scripts and just change the device.

I publish a script that easily creates my build environment and patches. I use it myself 3-4 times a year to move to new Ubuntu etc.

I will definitely try at least. Can you please point me to the exact direction? where is the script and how to set it up? I would start setting up the environment already. Router should come tomorrow around 18:00 CET and I would already try without even checking the stock firmware if i am ready by then.