Build for WNDR3700v1/v2 / WNDR3800 (discontinued)

I have built a rather minimalistic build for WNDR3700v1/v2 & WNDR3800 focusing just on the features I need. This is a basic router setup tailored for the WNDR3700v1/v2 & WNDR3800 hardware with essential statistics & packages, but without too much additional fancy stuff.

The build is based on the master branch and the stable 21.02 branch. All are based on ath79 instead of the old ar71xx.


I will retire this build. The WNDR3700v1, WNDR3700v2 & WNDR3800 are antiqued devices, especially regarding the wifi standards. The build has been in maintenance mode for some years now (after the ath79 transition), so now is time to close the chapter.
The build started in early 2011 using OpenWrt Backfire 10.03 (still with kernel 2.6.32.x...)
10.5 years and a bit over 2000 builds later, IPv6 support is mainstream and our Linux kernel is already 5.4 (almost 5.10).

November 2021: I did one more build for master and 21.02, as an upstream wifi bug was fixed this week, and it apparently affected also ath9k devices.
December 2021: One more build for master and 21.02, as wget was missing due to a package name change.

Current versions:

Branch Version
master master-r18312-3b20eb185b-20211211 (final build)
stable openwrt-21.02 owrt2102-r16399-c67509efd7-20211211 (final build)
stable openwrt-19.07 owrt1907-r11354-ffd4452f8b-20210606 (final build)

WNDR3700 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 included, in case somebody wants to utilize info in own builds.
See the patch files included in each build's download directory.

Good ipv6 support is now standard in Openwrt/LEDE, so I am dropping the IPv6 from the title. Documentation for the ipv6 configuration can be found at

Features included:

  • LuCI with HTTPS SSL support
  • USB storage automounting
  • Support for various file systems to enable most drives: ext2/3/4, FAT, HFS+, CIFS/SMB, (NTFS read-only)
  • WiFi button works to toggle Wifi on or off
  • WPS button works to enable automatic Wifi-authentication with WPS-enabled devices
  • Reset button works
  • IPv6: tunnel support for 6in4, 6to4 and 6rd included in the build.
  • QoS for traffic control The 'sqm-scripts' package is included, but initially disabled, as max speed needs to be adjusted to WAN connection speed
  • DynDNS support, also in LuCI
  • Adblock package (initially disabled)
  • Wake-on-LAN (WOL) LuCI module
  • Nano text editor
  • EFI/GUID partitions supported
  • ccrypt package included for file encryption

Note: these packages are NOT in v1, but only in v2 and 3800 in the master build:

  • adblock htop nlbwmon tree wget, fs-cifs fs-hfsplus fs-ntfs, Wake-On-Lan, UPnP, patch, diffutils, BCP38, ipset, ipsec, IPv6 NAT, Material theme, Openwrt2020 theme

Noteworthy changes:

  • r35964: added script helping to reinstall add-on packages after sysupgrade.
    See /etc/
  • r36467: iptables-mod-ipsec (and kmod-ipt-ipsec) included
  • r39183: WPS pin code set to the original value given by Netgear in the label at the router's bottom
  • r48730: Add support for 'adblock' with LuCI interface (adblock is initially disabled)
  • r49379 Change Luci to use Openssl instead of Polarssl
  • April 2019: vsftpd removed from the build. VSFTPD FTP server package with TLS/SSL support (access initially disabled by "local_enable=NO" in vsftpd.conf)
  • (r14899 master: wifi changed to wpad-basic-openssl (without WPA enterprise). Size saving of 100-150 kB.) Reverted change. full wpad again since r14954.

Note: As I build with standard kernel options, the release and snapshot modules should be compatible with my builds, in case somebody wishes to add modules to my build.

Note: A special version of my firmware that has the mtd write-protection removed from u-boot, u-bootenv and art partitions is available in subdirectory art_partition_binary_contents / firmware_with_no_write_protection. That enables you to edit/overwrite u-boot and art. That is highly dangerous and can permanently brick the router. But it might still be needed at some recovery operation...

---- Instructions for re-creating my build environment are in the next message ----


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.

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/owrt1907

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

  3. Download the firmware's four patch files: -main.patch, -packages.patch, -luci.patch (and -routing.patch) to /Openwrt. Note that the master build environment needs the master patches, and correspondingly the openwrt-19.07 environment needs the openwrt-19.07 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:

    • 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. 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.)
  2. Do the actual make: hnscripts/
  3. transfer files from bin/target/ath79 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.)

@hnyman, could I pick your brain on your builds? You include extra packages in your images compared to the stock builds, how do you maintain compatibility with LEDE/OpenWrt's package repos?

I have noticed myself that e.g. when I build with package set for router A and another for router B, even though they're both ar71xx, I cannot have router B pull from router A's repo. So I'm considering running stock builds for all the hardware and then repackaging with the Image Generator, so all the images can use the same repository; just wondering if there's a better way to go at it.


I keep separate build environments for LEDE, DD trunk and CC15.05 builds. And I compile only those packages that I include in the firmware image, so I don't try to download packages later from my own package repo. I build with standard kernel options, so I can download userspace packages from the respective snapshot repos, if needed.

I always build the firmware from scratch (after "make clean") starting from a short .config recipe that gets expanded to a full .config (which practice takes care of any possible changes in dependencies and in global defaults included in .config)

What do you mean that you can't "have router B pull from router A's repo" ? A signing checksum error? Some other error? I think that in principle you should be able to pull from any repo as long as the key used to sign the package list there is included in the firmware. So, you should make sure that you use the same key in both builds. (I have actually copied the same "key-build" and "" files for all my three builds.)

Thanks. Yeah, they're signing checksum errors. I use a single build environment (with ./scripts/env for different configs), I'm only building LEDE trunk myself. I haven't generated any keys, I thought those were auto-generated?

Edit: well nevermind me... It seems the errors were due to stale mips_34kc entries in opkg.conf :flushed:

[quote="Borromini, post:5, topic:64"]
I haven't generated any keys, I thought those were auto-generated?
[/quote]Yes, if there are no keys, the build system generates them on the first use. But you can copy the keys to/from another build system if you want to ensure that both use the same keys.

Good to hear that you got it solved.

Now that you are moving to a new router .. will you keep on updating this build? Been running your builds for as long as I can remember .. and never had any issue's with them :+1: :clap:

Likely yes, but with less intensity. I currently run R7800 as the main router and have a WNDR3700 running as a second unit to check this build. (R7800 has more powerful wifi, so I do not have an actual need for the second router any more)

Regarding WNDR3700, I will likely build LEDE rather often as there is continuous development, but will decrease the activity on Openwrt trunk and CC15.05 versions, as there is not much development happening.

1 Like

Hello. I really appreciate your hard work on these builds. I was wondering where i can find - LEDE master: lede-r2438-a245772-20161205 as stated in the post. It doesn't appear to be on the dropbox location.

Hello. I really appreciate your hard work on these builds. I was wondering where i can find - LEDE master: lede-r2438-a245772-20161205 as stated in the post. It doesn't appear to be on the dropbox location.

clone the git repository (available at among other places) and look for
commit a245772

David Lang

I removed that newest version from the download server after I noticed a problem with the new ddns package version. But I was lazy and did not edit the forum message. Christian has prepared a bugfix for ddns and that is already in the packages repo, so I will likely compile today the next version.

Now there is lede-r2438-a245772-20161206 that contains the fixed DDNS package.

1 Like

Just noticed the update. Thanks again for doing all the build work.

Apparently discourse prevents editing messages that are at least two months old. So at the moment I can't edit the first message any more.

EDIT: editing old message was enabled again. Great.

Newest version lede-r2752-2a72a916ab-20170104-musl1116 has been compiled with musl clib 1.1.16 that is not yet the default in buildbot, so no add-on packages can be installed at the moment.

there is some very weird problem going on. I don't know why but stunnel doesn't work on this builds
I have even compiled latest LEDE Reboot SNAPSHOT r3061 and it has the same issue

root@lede:/etc/stunnel# stunnel
Error relocating /usr/bin/stunnel: COMP_zlib: symbol not found

/etc/init.d/stunnel starts doesn't work either.

I managed to complain on IRC :slight_smile: but everybody assured me that its working for them diizzy even compiled his one and said it is working. hmm.

My build does not have stunnel, so this is offtopic. And I do not want to make this thread to a general help thread :frowning:

But despite that preword, some hints for you:

  • installing snapshot packages to private builds is always uncertain, as package, toolchain & tools options change sometimes sneakily breaking compatibility. It is better to build everything by yourself. Does it not work for you when you compile the build that has stunnel included by yourself?
  • When you build something and it fails to compile or work, re-compile it again after "make dirclean". Normal "make clean" (that you should run before each build) does not clear tools & toolchain. Dirclean clears them also. Last week has seen so many rather major changes on tools, toolchain, Makefile etc., thatdoing a full "make dirclean" is a necessity.

Pure guess, but I think that your problem may have been introduced by recent changes that have breaked package compatibility but without flagging the incompatibility (;a=commit;h=da5d060ac9171029cfde61ee45aa417696e45da0
and;a=history;f=include/;hb=f784b3e195cf5932347f0c2297b8604da93d12e3 ).

A fix a few hours ago may have fixed it:;a=commitdiff;h=f784b3e195cf5932347f0c2297b8604da93d12e3;hp=d9b1a55239dea616515426a705c00961dd7d0dd1

LEDE 17.01: lede1701-r3043-31b0640906-20170130

LEDE 17.01.0-rc1 is being currently compiled by the buildbot. This build should match it rather closely.

I backported LuCI support for 802.11r and 802.11w wireless config to my 17.01 build.

In case somebody is interested to implement that for their own 17.01 builds, the needed commits are available in

LEDE 17.01: lede1701-r3205-59508e309e-20170221 (match to 17.01.0 release)

The 17.01 build r3205-59508e309e matches the 17.01.0 release that is being compiled by the buildbot and should be formally released in the next few days.

1 Like

I can not find the commit the builds are based on anymore?

GitHub reports We couldn’t find any commits matching 'eb09d79c16'