Build for Netgear R7800

[layentara]

First of all, thank you for your great work on the R7800, hnyman!
I wanted to buy this router to turn it into a VPN router. So I just have three small questions regarding it:

• What speeds can I achieve with the OpenVPN client? Since it has this powerful cpu, I hope for 60-70mbps.
• Does the latest build I can download include the kernel 4.9?
• Does LEDE come with a DNLA server built in?

Best regards,
layentara

[hnyman]

@layentara

• What speeds can I achieve with the OpenVPN client? Since it has this powerful cpu, I hope for 60-70mbps.
• Does the latest build I can download include the kernel 4.9?
• Does LEDE come with a DNLA server built in?

I have not used OpenVPN, so no answer to that. (You might get better answers in the generic "R7800 exploration" thread instead of this build-specific thread)

kernel 4.9 is in the newest builds

No built-in DLNA, but there are packages available for that, e.g. minidlna. No experience from using them.

[layentara]

Thanks hnyman, I will ask in that thread again

[hnyman]

I will remove aiccu in the next build, as SixXS will stop operations in June.
https://www.sixxs.net/sunset/

[quote]Sunsetting SixXS

SixXS will be sunset in H1 2017. All services will be turned down on 2017-06-06, after which the SixXS project will be retired. Users will no longer be able to use their IPv6 tunnels or subnets after this date, and are required to obtain IPv6 connectivity elsewhere, primarily with their Internet service provider.[/quote]

If you are still using aiccu-based SixXS 6in4 tunnels, start looking for alternatives...

[Spots]

Hello hnyman

how do i get back to stock?

[hnyman]

@Spots

how do i get back to stock?

Easiest way is probably to use the TFTP recovery flash process, whick is described in Netgear R7800 exploration (IPQ8065, QCA9984) - #5 by hnyman

[Spots]

I tried this way, the flash process stops everytime at 75% and says that server doesnt response. If i try to flash your build it works.

[hnyman]

@Spots

I tried this way, the flash process stops everytime at 75% and says that server doesnt response

I am not sure if I have ever tried to flash back to OEM stock firmware with R7800 but it should work ok with the TFTP recovery mode.

This is pure guess, but if you have not set a fixed IP address to your PC from 192.168.1.X subnet, it is quite possible that the DHCP client in your PC tries to renew address during flash, fails, and changes IP address in the middle of a flash to a link-local 169.254.x.x address and that causes TFTP to fail. Windows PCs are especially eager to change IP rather quickly. (I have experienced that several times when I have been lazy with R7800 or WNDR3700 and have not changed to a fixed IP before the TFTP flash. then the TFTP transfer stops in the middle.)

I have used the TFTP2 GUI client, which makes it rather easy to prepare the TFTP transfer in advance before triggering the recovery mode.

[travmo]

I have flashed back to stock the way hnyman mentioned several times from my MacBook. Usually a smooth and simple process once you set a static IP and ensure your firmware is in the correct spot. Firmware transfers over in about 4.7 seconds, then restarts into the Netgear page.

[Spots]

Yes i did set a static IP address. But it doesnt work.
I tried to install it through putty with the command sysupgrade -n -F. This results in a bootloop. I could fix the bootloop by flashing LEDE over TFTP, but the stock one breaks at 75% everytime.

which tftp client do you use?

[fantom-x]

Hi, With the latest service release of LEDE, are there code/patch differences between this one and the standard build?

[travmo]

On Mac, I place the netgear fw in my user home folder, then in Terminal (I am sure the process is the same in putty), I run these commands:

tftp
connect 192.168.1.1
binary
rexmt 1
timeout 60
put R7800-V1.0.2.28.img

This moves the fw to the router and begins flashing the router.

[hnyman]

[quote="Spots, post:95, topic:316"]
I tried to install it through putty with the command sysupgrade -n -F. This results in a bootloop.[/quote]
Sure. In most devices you can't install the OEM image via sysupgrade. That holds true to R7800, too. (The few devices where you can do that (like wrt1900ac series), are exceptions,)

[quote="Spots, post:95, topic:316"]
I could fix the bootloop by flashing LEDE over TFTP, but the stock one breaks at 75% everytime.
[/quote]Sounds strange as the the whole TFTP functionality is in the OEM bootloader (u-boot) that is not modified by LEDE or Openwrt. LEDE (or Openwrt) firmware has no role in the TFTP recovery flash. So, OEM firmware images should be compatible with OEM TFTP flash routine...

@Spots

which tftp client do you use?

Like I said above:

@hnyman

I have used the TFTP2 GUI client

[hnyman]

@fantom-x

With the latest service release of LEDE, are there code/patch differences between this one and the standard build?

Yes. The changes are pretty much about tweaking some LEDs, config settings etc. to match R7800 better. Full diffs are available in the download directory as patch files, just like I say on the first message of this thread:

@hnyman

Full configuration and source code diffs are included in the download directory, in case somebody wants to utilize info in own builds.

[ykglove]

Hi，your build Firmware for R7800 is very good，but when I command line 'opkg install iptables-mod-tproxy',install fail,do you know what is happen,how can I fix it to install?Thank you！

[hnyman]

Like I already answered to your private message, you can't install kernel-related packages into private builds. There is a strict kernel options checksum check in order to prevent installing modules compiled with different kernel options, and possibly bricking the device.

[lostupi]

@hnyman

I also have a mvebu WRT3200ACM router and I build LEDE for it, but I have not started to publish the build.

I bought one
Waiting anxiously to test your build

[hnyman]

@lostupi

[quote="hnyman, post:102, topic:316"]I also have a mvebu WRT3200ACM router and I build LEDE for it, but I have not started to publish the build.

Waiting anxiously to test your build
[/quote]I have published links to my test builds for WRT3200ACM in the mvebu CPU frequency scaling thread...

CPU frequency scaling driver for mvebu (WRT3200ACM etc.)

If somebody wants to test the WRT3200ACM build that has CPU frequency scaling enabled, it can be found here, including all source code modifications. The build includes the same packages as my R7800 and WNDR3700 community builds. master-r14935-95b0751d0f-20201113 I am not going to start one more community build for the device series, but may post test builds every now and then.

[fantom-x]

@hnyman, I have noticed that you are using f_codel/simple.qos for your build and not cake. I am seeing latency issues with cake, but f_codel is even a bit worse. And I am not using your build, but might try.

[hnyman]

@fantom-x

I have noticed that you are using f_codel/simple.qos for your build and not cake. I am seeing latency issues with cake, but f_codel is even a bit worse. And I am not using your build, but might try.

Yes. I generally leave all packages to their default settings, except that I correct a few hardware-specific things like e.g. the default interface for SQM.

SQM has HTB+fq_codel / simple as its default, so I leave it for that. Each user can then configure himself which qdisc he wants to use. Both HTB+fq_codel and cake are currently included by default in SQM, so it is only about toggling a config parameter in /etc/config/sqm

I give advice about that in the first message of this thread:

@hnyman

• Note: the "simple.qos" script does not work optimally in R7800, as it uses HTB qdisc that seems to perform weakly on dual-core arm-cortex platform
• cake qdisc included for SQM, as it seems to perform better

The main reason for the weak "simple" performance with HTB+fq_codel seems actually to be HTB, not fq_codel itself. It is also possible to use "simplest_tbf" that avoids HTB by using TBF but still normally uses fq_codel. That simplest_tbf performed much better than simple (at least with kernel 4.4).

Extensive performance comparison of codel and cake qdiscs in R7800 can be found e.g. from https://github.com/tohojo/sqm-scripts/issues/48
A good summary maybe in https://github.com/tohojo/sqm-scripts/issues/48#issuecomment-270168000

The adoption of HTB burst in SQM and the move to kernel 4.9 has since then helped HTB/fq_codel performance somewhat.