Build for Netgear R7800

I am aware of that. I just need to know how to do the patch index when changing from material to openwrt, i.e.

diff --git a/themes/luci-theme-openwrt/root/etc/uci-defaults/30_luci-theme-openwrt b/themes/luci-theme-openwrt/root/etc/uci-defaults/30_luci-theme-openwrt
index ???????..???????? 100755  <-- HOW TO GET THIS?
--- a/themes/luci-theme-openwrt/root/etc/uci-defaults/30_luci-theme-openwrt
+++ b/themes/luci-theme-openwrt/root/etc/uci-defaults/30_luci-theme-openwrt
@@ -3,7 +3,7 @@
 if [ "$PKG_UPGRADE" != 1 ]; then
    uci batch <<-EOF
        set luci.themes.openwrt=/luci-static/openwrt
-       set luci.main.mediaurlbase=/luci-static/openwrt
+#      set luci.main.mediaurlbase=/luci-static/openwrt
        commit luci
    EOF
 fi

Are you trying to write a patch by hand to do this? If so, leave it out. The diff and index lines are completely superfluous.

--- a/themes/luci-theme-openwrt/root/etc/uci-defaults/30_luci-theme-openwrt
+++ b/themes/luci-theme-openwrt/root/etc/uci-defaults/30_luci-theme-openwrt
@@ -3,7 +3,7 @@
 if [ "$PKG_UPGRADE" != 1 ]; then
    uci batch <<-EOF
        set luci.themes.openwrt=/luci-static/openwrt
-       set luci.main.mediaurlbase=/luci-static/openwrt
+#      set luci.main.mediaurlbase=/luci-static/openwrt
        commit luci
    EOF
 fi

This patch (without the two lines) is valid in and of itself.

1 Like

Your patch still tries to disable Openwrt theme (by commenting out the line that sets the config item.)

Will you publish a build based on r10860 (which looks like the official 19.07.0 release if I got things right on github) eventually? Asking since I like your builds (using on two different models), but would like to prevent package version incompatibilities (i.e. kernel modules) once I need to install additional packages... Thank you.

1 Like

Impossible. Private builds will practically always have a different kernel version verification hash, as I have no intention of building all "kernel packages".

If you want to install additional kernel packages, either use the official release or build yourself.

2 Likes

use Kong r7800 build

As Kong is custom too, wouldn't that suffer from the same incompatibilities?

Thanks for pointer shelterx (and apologies for delayed response!). Went through config files & eventually found some old, erroneous dhcp entries. Reset router back to defaults & manually re-entered config and all is well now. Cheers.

no, Kong mantain a repository with kmod packages for his public build,
this of hnyman is a private domestic build useful only to his specific needs

I'm running hnymans build, it's like 10mb but Kongs latest is 23MB.... Blimey everything possible must be included, even windows10 emulation lol

I like hnyman's build too, but could not load WireGuard due to kernel incompatibilities.
I now have Kong's build running which has a lot already included, among other things WireGuard, hence the large size :slight_smile:

So, what things look like to me:

OpenWRT/LEDE is going the way of DD-WRT in terms of stability.

There's no comprehensive system of unit testing, continuous integration framework or anything of the sort which would prevent routine regressions from happening. It's a bunch of people hacking things together, just like DD-WRT.

So, there are only going to be a few select builds of this firmware along the way which are actually stable, and they will only be stable as long as your config falls within common use cases.

hnyman's 18.06 r7902 is stable (not sure about 5ghz, OpenWrt has always been flaky about it, and frankly 5ghz is a crap frequency so I don't care).

Flow Offload does a small increase in speed, but it is apparently more complex than I thought, and may still have bugs in it. 19.07 had some bugs about "flow offload regressions". I'm wary of enabling it, the risk is not worth the speed.

Without Flow Offload, I still get 700mbps+ downstream and 900mbps upstream on a Gigabit link, after implementing the two-line "echo" fix from this thread, which bumped it from 500mbps.

Of course, 17.x version of the firmware was giving 900mbps speeds without any tweaks or Flow Offload options. Never forget (tm). But it didn't have 802.11r, which I don't want to lose, and it gave C on Bufferbloat instead of A/B which 18.x gives.

But then again, maybe it was giving a C because it managed to saturate the line completely due to high throughput it allowed.

1 Like

I don’t see any hard data here that proves the build is unstable. If you have some log or other concerning specific points we would love to know so that the build can continue to improve.

I’m running the latest master build on three r7800s and I can nearly saturate my gig line in the B to A bufferbloat range with minor CPU tweaks plus software offloading. All my 40 devices are connected no sweat.

Don’t understand your distaste for the 5ghz band. Time to get over that and start enjoying 4x the bandwidth (80Mhz channels!)

2 Likes

For how long has that been running without a reboot or hang?

I can only speak for myself, but I've never had any reboots or hangs, the only real issue I've had was when the ath10k-ct firmware was added, but it's fine now.

I watch openwrt’s git and upgrade the firmware every 2 weeks or so depending on the commits (the only time the devices reset is for firmware updates) - I keep my settings and never have to do any maintenance - I’ll try some tweaks as per the exploration thread and that’s about it. :slightly_smiling_face:

All my smart devices are on a 2.4ghz only SSID. All my smart phones / ipads are on 5ghz only SSID with 802.11r enabled (all the roaming clients). Not all clients act alike so I tweaked my transmission power settings for ideal handover (driver default is not always the best setting! I lowered transmission power to ~24 for better handover with the setup in my house), set the routers up high and in the open for optimal radio physics, old clients were updated to minimum wireless N for 2.4ghz / min wireless AC for 5ghz, and I moved the APs around until I got the perfect balance (dropped a wired backbone at that spot).

All that combined with openwrt’s tweak ability and hnyman’s clean interface / regular updates has been great!

image

1 Like

Me neither. I am running OpenWrt Master SNAPSHOT, r11956-35ba9304c6 for 3 days without any issues.

How should I go about to fix these warnings when running newbuildroot.sh?

WARNING: Makefile 'package/utils/busybox/Makefile' has a dependency on 'libpam', which does not exist
WARNING: Makefile 'package/utils/busybox/Makefile' has a build dependency on 'libpam', which does not exist
WARNING: Makefile 'package/network/utils/curl/Makefile' has a dependency on 'libgnutls', which does not exist
WARNING: Makefile 'package/network/utils/curl/Makefile' has a dependency on 'libopenldap', which does not exist
WARNING: Makefile 'package/network/utils/curl/Makefile' has a dependency on 'libidn2', which does not exist
WARNING: Makefile 'package/network/utils/curl/Makefile' has a dependency on 'libssh2', which does not exist
WARNING: Makefile 'package/network/utils/iproute2/Makefile' has a dependency on 'libcap', which does not exist
WARNING: Makefile 'package/network/utils/iproute2/Makefile' has a dependency on 'libcap', which does not exist
WARNING: Makefile 'package/network/utils/iproute2/Makefile' has a dependency on 'libcap', which does not exist
WARNING: Makefile 'package/network/utils/iproute2/Makefile' has a dependency on 'libcap', which does not exist
WARNING: Makefile 'package/network/utils/iproute2/Makefile' has a dependency on 'libcap', which does not exist
WARNING: Makefile 'package/network/utils/iproute2/Makefile' has a dependency on 'libcap', which does not exist
WARNING: Makefile 'package/network/utils/iproute2/Makefile' has a dependency on 'libcap', which does not exist
WARNING: Makefile 'package/network/utils/iproute2/Makefile' has a dependency on 'libcap', which does not exist
WARNING: Makefile 'package/boot/kexec-tools/Makefile' has a dependency on 'liblzma', which does not exist
WARNING: Makefile 'package/network/services/lldpd/Makefile' has a dependency on 'libnetsnmp', which does not exist
WARNING: Makefile 'package/network/utils/nftables/Makefile' has a dependency on 'jansson', which does not exist

Those error messages should vanish once you have updated & installed feeds.
Remember to also update and install feeds regularly.

Those packages are quite old ones, so I do not think that those error messages are valid in global perspective.

1 Like

3 days is nothing to brag about.