Build for Netgear R7800

Is that included in the latest master?

Since five days ago.

1 Like

I ready done it,But it doesn't work

Just how stable is "stable openwrt-19.07 owrt1907-r11182-5af8da3787-20200814 (ath10k-ct)"?

Has anyone ran it extensively non-stop for say, a month, with wireless active, no reboots? Does the performance still handle near-gigabit speeds?

No, as it has been built on 20200814 = two days ago...

1 Like

I thought it was about time I upgraded the firmware on my R7800 from LEDE 17.01.? and found your custom builds. They include just the packages and setup I am interested in. Thank you for sharing.

I flashed my R7800 with the owrt1907-r11194-19b8696dd7-20200828 factory image via TFTP and all went smoothly. Initially I just set a password and had a play but noticed it would reboot quite regularly. After testing a bit more it does only seem to happen while I am using LuCI. On several occasions now it has been stable for several hours but as soon as I login to LuCI webui and it starts loading the overview page it has rebooted.

I have just setup a syslog server to capture some logs in the hope that it will give some clues. In the meantime I thought I would ask if anyone has any ideas about what I should be looking into.

Try a master build, the stable builds are on kernel 4.14 and there were bugs that resulted in reboots that have been fixed since.

Thanks for the reply. I have just flashed with mmaster-r14363-7f0cb91d71-20200901. Only changed password, dropbear listen interface to lan only and enabled logging to a server for now. Will monitor stability today before enabling wifi and making further configuration changes.

In general you can move between recent builds (including between stable and master) and keep the existing configuration, you don't have to start clean every time. But it might be a good idea to start fresh if you have a really old config.

Thanks. The router still reboots but this has only happened when I am using LuCI. It seems perfectly stable in between. Mostly this happens as soon as I login and the last entry in syslog server before the reboot is from uhttpd

luci: accepted login on / for root from 192.168.1.1

Not terribly helpful as to why it is causing it to reboot. Maybe I should try an older release but newer than the 17.01.4 I had installed previously. That was rock solid I don't recall it ever crashing. Ideally I would like to use a build that has hnyman's changes. I will look at setting up a build environment later.

Earlier the random reboots were thought to be related to jumbo frames, that were handled badly by the kernel.

I've just swapped my router out so I've had chance to play with the old one more now. It was suffering reboots. I could almost guarantee connecting to LUCI using Edge would crash it. It was also at random times outside of the GUI use as well though.
I reset to defaults and still suffered the same issues (I have a separate post on some of it).

At the moment I've just switched it back to the standard OpenWRT software (OpenWrt 19.07.3 r11063) and have found Edge now works. I'm not sure why but seeing as pretty much everyone else has no issues, then it is probably something with my hardware going awry.

This was pretty much the same story for me. Every reboot happened as a result of me connecting to the LuCI web UI or opening a new page in it (using Vivaldi). I had planned to try older builds but didn't get round to it for a day or so. During this time it was stable. Only 3 clients (2 wired, 1 wireless 5GHz) connected during this time but happily browsing, streaming video and running speed tests etc.

I was convinced that once I started using LuCi again it would crash, but so far this hasn't happened. Now been up for over 2 days.

I had been starting to suspect my hardware, maybe power supply as no one else seemed to report any issues. Also noting in the any logs I could see after the LuCI login event. I did also have an strace running on the uhttpd process when it crashed during a login to the web UI. Nothing unusual in the system calls for that process at least.

Maybe the power supply struggled when the cores ramp up during the login. I have noticed load on both cores jump up briefly during login. Running traffic only seems to increase the load on core 0.

Still a bit of a mystery, but interesting that you had a similar experience.

Try adding the following to /etc/rc.local (or try it out first to see if it helps, then add it to rc.local).

echo ondemand > /sys/devices/system/cpu/cpufreq/policy0/scaling_governor
echo ondemand > /sys/devices/system/cpu/cpufreq/policy1/scaling_governor
echo 800000 > /sys/devices/system/cpu/cpufreq/policy0/scaling_min_freq
echo 800000 > /sys/devices/system/cpu/cpufreq/policy1/scaling_min_freq
echo 75 > /sys/devices/system/cpu/cpufreq/ondemand/up_threshold
echo 10 > /sys/devices/system/cpu/cpufreq/ondemand/sampling_down_factor

Mine used to reboot as well, but after this not anymore. I think it has to do with a too low frequency, but of course i cant prove that.

1 Like

Or you can just run performance governor like I do and not worry about it. Keep an eye on the temps though, just in case, but you shouldn't see any significant jump, maybe 1-2C.
cut -c1-2 /sys/devices/virtual/thermal/*/temp

echo performance > /sys/devices/system/cpu/cpufreq/policy0/scaling_governor
echo performance > /sys/devices/system/cpu/cpufreq/policy1/scaling_governor

owrt1907-r11210-29b4104d69-20200907
The build is equivalent to the 19.07.4 maintenance release that was tagged today.

The last committed changes to 19.07 before the .4 maintenance release were actually the backports of ath10k chip -ct firmware versions from master to 19.07, so that master and 19.07 currently have the same version of -ct firmware.

https://git.openwrt.org/?p=openwrt/openwrt.git;a=shortlog;h=29b4104d69bf91db17764dd885e9e111a373f08c

Just a short observation for whatever it's worth. I purchased a R7800 this week and immediately installed (TFTP) this build on it, without flashing any other OpenWRT build beforehand.
The router didn't come up correctly, and it took me some time to understand that actually it hadn't started its DHCP server. (When I configured a machine to 192.168.1.100 manually I could connect to the router at 192.168.1.1.)
If I'm not mistaken, the reason seems to be that in the build, there's no dhcp config file included. Without that file, the server seems not to start at all. Also, from the web interface, you won't be able to start it, as the Network/DCHP and DNS menu is simply showing... nothing.
The solution is to manually create the config file (via ssh) in /etc/config/dhcp (you can find sample files elsewhere just copy-paste the main options).

I assume you "upgraded" from stock to Openwrt (using the *factory.img, version 19.07.4?).
It is not normal that after a fresh flash the router is in a helpless state. The files under /etc/config should be there and provide a minimal functionality.
Maybe you should perform a "reset to defaults" and take it from there.

I would flash it again via the OpenWRT web interface and not keep the config, reset to defaults. All the config files should be there and DHCP should work by default. Not sure what may have gone wrong via TFTP.

Also, from the stock firmware you can simply use the (stock) web interface to flash OpenWRT, at least that used to be the case, don't know if Netgear may have locked it down recently.

No, I upgraded from stock Netgear firmware and the system came up in a state that was not really ideal, I only could access it with a fixed IP.

Well yes that's what I would think too. But I'm not able to check the image file to see why it is that way. Maybe this image was intended only for upgrading from stock-openWRT?

Well, for me the solution to manuallly create the config file solved the issue.
But if somebody here can check the source tree for building these images, it might be worth adding a default dhcp config file :wink: