Build for Netgear R7800

Thanks @hnyman , I compared the ubuses and I've got 2 more addresses and 4 more routes listed. Especially the addresses seem awkward:

        "ipv6-address": [
                {
                        "address": "::3e37:86ff:fe2a:c511",
                        "mask": 64,
                        "preferred": 604764,
                        "valid": 2591964
                },
                {
                        "address": "2a01:90a0::3e37:86ff:fe2a:c511",
                        "mask": 64,
                        "preferred": 604354,
                        "valid": 2591554
                },

The last one has mask 128 and looks like yours.
First I'm going to get some IPv6 knowledge so I know how this works, it is quite different than IPv4. Then if necessary I'll open another topic for this. Thanks for showing the commands.

Update, I contacted the provided and they showed me they only hand over the third (mask 128) address to me. So the two above are created by DHCPv6 or a script. Any thoughts?
They also mentioned the gateway is pointing to an internal address fe80::1, while we would expect an external? Provider says nothing's changed over the previous months.
As DUID the MAC address is sent without additions.

Also, I found a network status screenshot from my first and previous firmware master-r13628-870588b6eb-20200625, and this only showed an IPv4 upstream! So this explains the change ...

The nicest way is to get this working properly, but an alternative is to shut that IPv6 upstream, while leaving it available on the internal network. Is that simply possible? I've tried some disabled but the upstream does not disappear and the two minute delay stays, not only for package management, but also for some websites and apps on pc and phone ...

I am experiencing similar issues on 2.4 GHz. Is there any known fix yet?

I'm trying to install package kmod-nf-nathelper - this refuses to install and complains about a version conflict. I see the package is version 5.4.66-1 while the kernel is 5.4.65-1. Is that the cause?
How to fix this?

image
2.4 GHz on 16 meters and some walls. I would expect symmetrical speeds and have seen higher speeds.

For reference, what 5 GHz does on this distance:
image

1 Like

That is part of the reason. Kernel version has been bumped since I last did a build.

You can't fix it.
Due to precautions, there is strict (kernel version & options based) checksumming for kernel kmods, and in practice you can't install additional kmods to private builds (unless the kmods have been complied along the main firmmare).

If you need additional modules, you have to options:

  • use a release or snapshot firmware from OpenWrt repo and install the additional kmods
  • compile a personal version with the kmods that you need.

Clear.

I had it in my previous WNDR-3700 and it is supposed to fix strange ftp issues (I see now in the R7800).
Is it interesting enough / small enough (7 KB) to include in your release? I see it uncommented with a #. I'd prefer to stick with your master build :wink:

The 2.4ghz band is overloaded. You are probably getting interference from somewhere (baby monitors, virtual networks, neighbors, Bluetooth, and nearly every wireless device ever).

40mhz wide channels frequently default down to 20mhz channels. With a 2x2 client, PHY speed is 144mbps (you’ll never get this).... add in interference + overhead... anywhere between 60-100 is a good result.

See here:

Hi guys,

Does this fix affect the r7800?

https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=1c6d45644a54e50b6445bbc63eff1ae34b2f1e2e

Thx.

Not quite sure, but I think that it does.
And it might help to fix random disconnections that have been present some weeks.

(The new patch claims to fix 321-mac80211-optimize-station-connection-monitor.patch that was introduced in August. Took a while to figure out that the fix is not for the upstream mac80211, but for the local tweaks/optimizations done for OpenWrt. Not quite sure why nbd did not directly modify his original patch...)

I spent a lot of time with DD-WRT and it's been TREMENDOUSLY unstable compared to OpenWRT/LEDE until the last year, where OpenWRT matched its instability.

Now for both types of firmware, the algorithm is the same: only stick to firmware version which was proven stable via suffering/sacrifice of other users.

Don't believe anyone claiming that whatever's latest on "master" is stable - ever. We are the alpha- and beta-testers for these firmwares, and if you don't want to be one, stick to a proven build.

I still use "R7800-master-r11167" build which I got from this very thread because someone proved that it ran for 50 days with wifi and SFE enabled, with no obvious issues.

I did have to add the startup commands to squeeze more speed out of it.

As for DD-WRT, the stable build for this router is Kong's 37495M . As far as I know.

That is why there are two different flavors. 19.07 focuses on stability and device support vs Master is cutting edge (beta).

I too moved over from DD-WRT to OpenWRT because of the irregularity in the builds. Master has been good, I’ve seen no evidence that master is unstable - I run master on my daily routers. If stability is your top concern - 19.07 is production quality - I’d run hynman’s 19.07 build.

If you are looking for stability, then you need to stay with a stable branch. Master or DD-WRT are rolling releases, which means rapid changes everywhere. My DD-WRT builds were something in between. I merged, than ran my tests fixed bugs, created a release and then commit the changes. This has been a very time consuming process, that's why I switched to Openwrt:-)

With 19.07 I have pretty much no work at all, sync,build,flash, done!

5 Likes

I still keep getting reboots on your stable and master builds. It always happens when using LuCI. But not every time. The router would also appear to be very stable if I refrained from logging into LuCI.

I would love to know why this is happening with my device because I would like to use your builds. They contain all the packages I am interested in and I can then try newer builds without having to install packages again or create my own builds. Many thanks for all your continued hard work with this!

I have now switched to standard 19.07.4 build and installed and setup a few of the packages I require. This has so far been stable and so far no crashes when using LuCI. One possibly notable difference is that I have not setup SSL for LuCI. I wonder if this, in combination with my browser, could have been causing the reboots?

Try logging in with ssh and run logread -f and see if it catches any error before it crashes.

Thanks. I just put a build on to test and it still crashes. I had logread -f running but the last entry is just the login event.

Thu Sep 24 10:58:58 2020 daemon.err uhttpd[2154]: luci: accepted login on / for root from 192.168.1.10

Once it crashed before the login page even finished loading and nothing printed in the log.

do you have any specific additional packages installed for luci, or is this just the base one?

This happens with a freshly flashed image (TFTP) of one of these builds even before any configuration changes.

But the standard OpenWRT 19.07.4 is fine. Even when some of those extra packages are installed.

Just try this, doubt it will help.
option http_keepalive '0'
in /etc/config/uhttpd

EDIT: Corrected option

That's really strange, there are only tiny changes in my build, that have nothing to do with the webinterface and I have not seen a crash with any browser on a handful of units, that use my builds.

If it works with regular openwrt builds, it should work with mine. My first guess is, that due to size difference of the firmware, locations of apps and configs differ in flash, if you have a bad flash cell or corrupt ubifs this could happen. On the affected router, can you send me output of command: dmesg