Netgear R7800 exploration (IPQ8065, QCA9984)

The stable version is still on 4.4 kernel,so I go with master.
But I will try to go back to stable version later,see if it works

Currently I run this build
LEDE Reboot SNAPSHOT r4694-e7373e489d / LuCI Master (git-17.223.47793-8bc1971)
and it worked fine.
But after 20 days of uptime router rebooted. I didn't find something wrong in the logs after it.
What is most stable Lede build can I use? Is it official Lede 17.01 or smth from hnyman's list?

What's so special about 4.9? 4.4 has a bunch of stuff backported from newer kernels. It's not stock.

Sorry to quote such an old post, but I do experience the same problem...

I have 2 routers, Linksys EA8500 and Phicomm K3. EA8500 has an IPQ8064 which is much like R7800, and K3 has BCM4709. They all have the same problem as dissent1 described in that post (reproducible by all WiFi and wired connections). Data streams going out of the router are capped at 300Mbps (<100Mbps for WiFi) but streams flowing into the router are just fine.

EA8500 is running at revision r49xx which was built several days ago without any additional patches missing from master, and K3 is running at an old build made in May. Source code for K3 is uploaded here, I have done basic porting only so it was also a "clean" build.

Maybe we can make a wild guess that something went wrong in common logic in kernel, since different platforms and different PHYs are affected...

1 Like

Actually it was my bad with that iperf test capped at 10-15 mbits - I’ve backported some patches from upstream kernel and missed some other dependencies.

Anyway there’s really smth strange going on because mt7621 (2x880mhz mips) device outperforms ipq8064 and on par with ipq8065 with NAT/QoS traffic.
If someone wants to test performance difference there is k4.13 stmmac driver in my tree that you can pull.

I've recently switched to an mvebu router and found there to be a massive difference. It's more responsive, the Ethernet speeds are more consistent,, lower latency too. The wifi is not as good but I think it's worth it.

dissent1's right, there's something weird going on. The R7800 should not be performing like this.

I second this.
I own TP-Link Archer C2600 with IPQ8064 and it has troubles keeping up with 250/20 Mb/s connection with SQM layer_cake. I've seen people in this thread pointing out a low performance of units based on IPQ806x compered to the Linksys devices. I even asked about it here and got no response.

Apparently Netgear R7800 can't handle 300 Mb connection with LEDE. It's laughable really. I've also seen reports that my C2600 could previously handle 800 Mb/s connection of NAT alone. Now it can't even do 500 Mb/s. That was from a guy that actually tested this router some time ago and repeated those test recently. He said that "they changed something with the switch (inside LEDE) and now there is a problem with 500 Mb/s connection".

It’s not the switch driver, I use different switch driver. And iperf to the R7800 shows gigabit speed, probably meaning that eth driver also acts more or less ok. It’s smth different, that relates to forwarding. Or maybe eth driver eats up a lot of cpu so not much left for natting/forwarding.

Try pulling stmmac update linked above.

Tried the stmmac patch but make no difference.

It can handle close to a gigabit across the LAN/WAN port in NAT mode, I (and others) have tested that extensively.

Edit: that's with the FASTPATH patch applied btw, didn't test without.

With Fast Path even WR1043ND v4 with 750 Mhz Single Core MIPS CPU can get near Gigabit speeds.

Another platform using stmmac had the same problem (low upload speed) and users found a workaround here. I could not test this as I don't have access to my router now...

I guess it's not our case

Wonder if it may help us somehow
If it affects nvmem reads, could be that nvmem returns incorrect value

Has anyone experimented with the hwrng in this device? I have an implementation I am working on that needs a significant amount of sources of entropy and what I am currently finding isn't enough for my scenarios. Well, it's not enough to make me comfortable, that is. Thank you.


There is discussion about that in this same thread...

As far as I know, the hwrng in R7800 is still a pseudo-rng, but produces good amount of entropy that can be piped into kernel pool via the rng-tools package.


It seems that something changed in 17.1.3 vs 17.1.2 in openssl results of dsa verify:
I tested both. Please see last number.

17.1.2 results:
| r3435 | ARMv7 Processor rev 0 (v7l) | 6.00 | ARMv7 Processor rev 0 (v7l) | 56.15 | Qualcomm (Flattened Device Tree) | 1.0.2k | 140149300 | 181368490 | 131009190 | 67100080 | 24305440 | 8929690 | 65237670 | 56827900 | 51760130 | 131.7 | 5914.3 610.9 | 593.7 |

17.1.3 results:
| r3533 | ARMv7 Processor rev 0 (v7l) | 12.50 | ARMv7 Processor rev 0 (v7l) | 56.15 | Qualcomm (Flattened Device Tree) | 1.0.2k | 140083880 | 180450300 | 130343250 | 67257900 | 24805460 | 8888870 | 63706450 | 55427170 | 50563070 | 132.8 | 6013.6 607.1 | 1.3 |

Do you know why?

Which patch did you apply for that compile to work?

Not sure what you are referring to?

I am running latest LEDE 17.1.3 on my R7800. The 5GHz radio still crashes after running several hours.
I have been watching on this issue for a few months. Things didn't get better.
I am planing to flash back to the OEM firmware instead.

I have been having issues with my 5Ghz network for some time. After a few days (4 or 5) my network was dead. The hotspot was working but none of the devices could connect to it. It only happened to 5 Ghz network. My 2.4 Ghz WiFi is rock solid.

After an hour of research I came across a thread mentioning the fix for it. Apparently you need to include this link in your config. It needs to be placed in config wifi-iface section.
option wpa_group_rekey '0'

After this little change I resolved all of my issues with 5 Ghz network. I don't have a link to the thread explaining what's causing it but I do remember the solution.