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.
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 (kmod-fs-ntfs3 in master), 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
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)
miniupnpd settings: leave upnp off by default in /etc/config/upnp
IEFT BCP38 support
iptables-mod-ipsec and kmod-ipt-ipsec
Wake-on-LAN LuCI module
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.
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 newBuildroot.sh file and the three/four *.patch files to /Openwrt
Run newBuildroot.sh. It creates the complete build environment and applies the patches
Build firmware with hnscripts/updateNmake.sh
Detailed explanation of the steps in the build environment creation process :
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
Download the "newBuildroot.sh" file from my newest firmware build package to /Openwrt and chmod "newBuildroot.sh" to be executable
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.
Verify that "newBuildroot.sh" references the correct patches: Check that the FILESTAMP variable definition matches the timestamp in actual patch names.
Run "newBuildroot.sh". 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"newBuildroot.sh", 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/reinstall-packages.sh 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.
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
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:
cd into /Openwrt/master
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.)
Do the actual make: hnscripts/updateNmake.sh
transfer files from bin/target/ipq806x to wherever you need them. I use a script: hnscripts/mountNcopy.sh
Explanation of the scripts in /hnscripts:
updateNmake.sh is the main build script that updates sources and builds the firmware
mountNcopy.sh is the script that I use to copy firmware files to my PC
newBuildroot.sh is the build environment creation script
Other scripts (timestampVersion, parallelcompile, singlecompile, kernelcompile, copypackages2tmp) are just helpers. createbuildinfo.sh 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.)
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.
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)." https://www.bufferbloat.net/projects/codel/wiki/Best_practices_for_benchmarking_Codel_and_FQ_Codel/
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 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 https://github.com/lede-project/source/pull/533
PR533 has been accepted and the source code is included in the main LEDE repo.
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.
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
but seems like I will have to start building myself again
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.