Custom firmware build for R7800 v. 1.0.2.54SF

[jcouch93]

Voxel thank you for your hard work! Also thanks to kamoj! I do have a question though... I installed the latest version yesterday (v1.0.2.54SF) and in the beginning (after configuring wireless but before configuring anything else) I was able to change the names and device types with no issues. However, once I made the other config changes (DHCP Reservation, Port Forwarding) I lost the ability to change the entries (I just get the dreaded blank screen). I have read through multiple threads and one had a comment about the DHCP Reservation may cause the issue? Should I downgrade to .50? Can I just downgrade without a reset or should I reset? Thanks for the help!

 

[Deleted member 22229]

Name your devices before you set up reservations i did this and it works fine.

 

[jcouch93]

Name your devices before you set up reservations i did this and it works fine.

Thanks Kal-El. I'll have to remember that but a workaround I found was to use the app on my phone to change it and even though the app says "setting failed" it DOES set the name and type.

 

[Supersaiyan_IV]

I'm still playing with compiler options. Thanks for your suggestion,

Regarding version of compiler, there are significant problems with newer versions of GCC. I've checked a lot of versions. First, I have to provide compatible codes with pre-built modules from NG (4.6-linaro). Second, 3.4.x kernel is not compatible with GCC > 4.x. Compilation bugs. But BTW 4.8.5 I use is producing very good codes.

Voxel.

GCC 4.8.5 is indeed very good, only GCC 8.x comes close, GCC 5.x, 6.x, 7.x has quite trash performance when it comes to networking. Linking GCC 8.x bins against GCC 4.x compiled libs works, but, you'd need to ignore a whole world of new compiler errors/warnings since it's GCC 8.x after all. Some misalignment issues can be worked around with -faligned-new (C++17 extension), but it's an ugly workaround.

Another approach is updating Binutils (build it with --enable-plugins --enable-gold), might achieve some improvement with -flto. Then using GCC's wrappers for gcc-ar, gcc-nm and gcc-ranlib (instead of standard ar, nm, ranlib), you can enable -fuse-linker-plugin, meaning whole toolchain is aware of LTO's GIMPLE trees, and remove need for -ffat-lto-objects - greatly improves the quality of LTO's inter-procedural optimization. Proceed with LTO compiling without debug info (eg. -g disabled), since LTO with debug information (works but) is experimental in GCC 4.8.5 - LTO with debug information is stable beginning from GCC 8.x. Usually preferable to use gold linker than bfd, but usually bfd simply works where gold fails.

More fun things to do is supplying (can be found in 'cat /proc/cpuinfo'):
--param name=value

l1-cache-line-size
The size of cache line in L1 cache, in bytes.
l1-cache-size
The size of L1 cache, in kilobytes.
l2-cache-size
The size of L2 cache, in kilobytes.
Use it eg.:
--param l1-cache-size=32 --param l1-cache-line-size=64 --param l2-cache-size=6144​

Which will target the R7800's particular ARM CPU model slightly better. Won't even bother with suggesting PGO, because it'll be a huge hassle.
https://gcc.gnu.org/onlinedocs/gcc-4.8.5/gcc/Optimize-Options.html

Feel free to call me out on any bs I've might have unintentionally said above. Cheers.

 

[Deleted member 22229]

2 weeks and counting with this firmware and not one glitch or issue.

 

[Supersaiyan_IV]

Another fun thing you can do @Voxel is copy an ARM-friendly GCC 4.8.5 (the whole folder will do) to the R7800, navigate to gcc/bin/ and see what native flags it prefers with "gcc -### -E - -march=native". If GCC 4.8.5's "-march=native" detection is sub-par you can re-run the command with a GCC 8.2.0 to match/compare, as "-march=native" detection is known to sometimes be a hit&miss. Can't wait to see what you'll cook up next!

 

[Voxel]

Another fun thing you can do @Voxel is copy an ARM-friendly GCC 4.8.5 (the whole folder will do) to the R7800, navigate to gcc/bin/ and see what native flags it prefers with "gcc -### -E - -march=native". If GCC 4.8.5's "-march=native" detection is sub-par you can re-run the command with a GCC 8.2.0 to match/compare, as "-march=native" detection is known to sometimes be a hit&miss. Can't wait to see what you'll cook up next!

Well, I suppose I should know it better than GCC .

In general "-march" could set up some limitation. You can browse our with sfx2000 discussion and disagreement re: what options are better and "-march" vs concrete "-mcpu" for Cortex-A15 and IPQ806x. Somewhere in the very first thread re: my custom build for R7800.
Voxel.

 

[Supersaiyan_IV]

Well, I suppose I should know it better than GCC .

In general "-march" could set up some limitation. You can browse our with sfx2000 discussion and disagreement re: what options are better and "-march" vs concrete "-mcpu" for Cortex-A15 and IPQ806x. Somewhere in the very first thread re: my custom build for R7800.
Voxel.

Read up on your discussion, and I find it interesting that most of the performance benchmarks are very similar performance-wise, and that none of them test network-stack's packets-per-second throughput vs. CPU usage. Don't have any strong opinions regarding "-march" vs. "-mcpu", but my conclusion is that there's likely more to be gained by bringing hot code closer to the CPU cache.

This means that the next significant step probably is PGO, with or without LTO. Grill a PGO build with heavy network loads eg. torrent + chrome + speedtest, stressing the R7800 generating profile-data (-fprofile-generate=path). Then rebuild using the gathered hot/cold function profiles (-fprofile-use=path).

There's also the alternative of manually identifying hot-functions, usually by creating a #define with the section and hot GCC __attribute__'s, placing them in a separate .text.hot segment, which is linked using a separate *.ld link-script, whose section-size may never exceed the CPU's L1 cache size (eg. .text.hot ALIGN(0x2000)), such that hot code never has cache-misses, as long as the hot functions only call each other.

 

[Gouzmalix]

I've had one issue thus far. The process "sh" takes up about half CPU power. Based on the load averages, it's been like that for awhile...

First I've had issues with miniupnpd causing unnecessary CPU load, now a random, sh process? What is going on?

Edit: Using ps, I've been able to narrow down the culprit to a more descriptive "sh /etc/rc.local"

 

[Easy Rhino]

So, with this .54 build when i'm on the other side of the house from the R47800, I can't connect to the 5ghz network, either with my phone or my laptop (they used to connect okay on version .52 or .53) The laptop connects but gives an "no internet" error. The android phone rejects with an error along the lines of network-association-disabled. 2.4ghz is fine.

When i'm closer range, the 5ghz connection worked fine, also.

Backing up to up to .53SF-KF left the problem in place.

Weirdly, changing the 5ghz channel from 36 to 52 (DFS) seems to have let my clients connect on the edge of the house?

So it doesn't really seem like it should be happening, high chance of user error, but just though I'd report it.

Incidentally when I tried to downgrade from 54 to 53SFKF using the web UI, it bricked my router. I needed to do a upload of the bios using TFTP, which then worked.

 

[Voxel]

Don't have any strong opinions regarding "-march" vs. "-mcpu"

The option "-march=armv7a" used in the stock FW generates ARMv7a instructions when Cortex-A15 is superset of ARMv7a instructions. Of course IPQ806x is Krait, not real Cortex-A15, but according to my investigations and tests it is practically Cortex-A15. So if I use "-march-armv7a" I'll get speed degradation.

Well, investigation of optimization is continued, thanks for your hints. But stability is in the first turn.

Voxel.

 

[Voxel]

I've had one issue thus far. The process "sh" takes up about half CPU power. Based on the load averages, it's been like that for awhile...

First I've had issues with miniupnpd causing unnecessary CPU load, now a random, sh process? What is going on?

Edit: Using ps, I've been able to narrow down the culprit to a more descriptive "sh /etc/rc.local"

Do you have kamoj add-on installed? In 1.0.2.54SF rc.local is not used (just exit).

Voxel.

 

[Voxel]

So, with this .54 build when i'm on the other side of the house from the R47800, I can't connect to the 5ghz network, either with my phone or my laptop (they used to connect okay on version .52 or .53) The laptop connects but gives an "no internet" error. The android phone rejects with an error along the lines of network-association-disabled. 2.4ghz is fine.

When i'm closer range, the 5ghz connection worked fine, also.

Backing up to up to .53SF-KF left the problem in place.

Weirdly, changing the 5ghz channel from 36 to 52 (DFS) seems to have let my clients connect on the edge of the house?

So it doesn't really seem like it should be happening, high chance of user error, but just though I'd report it.

Incidentally when I tried to downgrade from 54 to 53SFKF using the web UI, it bricked my router. I needed to do a upload of the bios using TFTP, which then worked.

Something strange: you compare 1.0.2.53SF-KF vs 1.0.2.54SF. No difference in Wi-Fi QCA drivers. There was updated drives for Wi-FI 1.0.2.52SF vs 1.0.2.53SF(-KF)/1.0.2.54. So...

So it doesn't really seem like it should be happening, high chance of user error

Voxel.

 

[Gouzmalix]

Do you have kamoj add-on installed? In 1.0.2.54SF rc.local is not used (just exit).

Voxel.

Yes, that is correct. I have kamoj's add on for enhanced debug statistics installed. So I guess it's caused by that.

 

[Darren_H97]

Voxel, thank you for your great work!
It's my first NG router and without your firmware & Kamoj's improvements for OpenVPN, I would have returned the box after day 1. Netgear should do something nice for you (yeah, sure ), as you help them to not refund their fancy marketed routers to people who would like to use more than 10% from their capabilities.

Installation & basic configuration was not difficult, I can mention only the false warning: "You are trying to download firmware with version V1.0.2.54SF which is older than the firmware with version V1.0.2.36 you had.". Fortunately it was just a warning so I could press <OK> and continue.

For the advanced configuration, I had some small challenges - that maybe you will take some in consideration and update the ReadMe document with proper info for those not so experienced with Linux (or too lazy to use google):
- what is the preferred filesystem if you want to use USB stick or USB HDD (ext2, etx3, ext4, etc.) and what procedures must be followed when some wants to turn off the router or just eject the storage without causing issues.
@kamoj: maybe an eject button in the improved debug.htm add-on?
Or @Voxel: maybe an option to use the WPS button to eject the storage and turn off USB LEd when is ejected succesfully? (for those who doesn't need WPS)
- an workaround for those which don't have a Linux machine nearby to partition & format the USB storage correctly (if possible, using the router itself, after activating telnet from debug.htm), and commands to download & extract the setssh.tar directly with the router.
- for those with a strange internet connection (e.g.: 4G/LTE), OpenVPN server will require some troubleshooting and not everyone has access or knowledge to use packet capture traffic for that, and on both ends of the connection (client & server). For me, traffic started to work bi-directional after I've added (in the /etc/init.d/openvpn script) the option mssfix 1394 (and then restart). I've tried initially with option link-mtu 1394 (and fragment) but it didn't solve the issue, so I replaced that with mssfix - and frankly I'm glad that it didn't work out the box, as PMTUD sometimes is ignored by some clients, and I didn't wanted OpenVPN to fragment 1500bytes traffic that will uselessly will multiply the VPN packets.
I had the clients connected via LTE, and the R7800 with ADSL. For the LTE connection I had decreased the MTU size of EdgeRouter X's WAN interface to 1420 also (after checking with ping -do-not-fragment from which size the ping to next hop router will work, while decreasing the size of ICMP packets **).
And at the very beginning I've changed the ports of the OpenVPN server to use one within the range of UDP traceroute by Linux/Cisco devices (33434 to 33464), as some small providers might block others/well known ports used for various servers & services.

On my to-do list I have left for the moment:
- configure Entware crontab to do an automatic backup of the config files I've changed since last backup + some files from USB storage and copy them with scp to a NAS
- configure automatic reboot once a week
@kamoj: maybe an option to see Entware crontab content in the debug add-on?
- configure syslog to be sent to a syslog server
- check for alternatives of using WDS with a good old WRT54GL (with dd-wrt) that was offering slow Wifi in the garden. I was a little bit surprised that NG removed WDS support from their latest models, but.. it might be safer for the users (and better for their WLAN extenders business )

Once again, a big thank you to you and your team!
________
** For reference, the Windows command is: ping -n 3 -w 100 -l 1420 -f aaa.bbb.ccc.ddd , where: aaa.bbb.ccc.ddd - is the next-hop router (provider gateway or other public IP closer to you that is normally ping-able with small packets), and the parameter -l (L : packet size) should be changed (up or down) until the ping answers changed from "Reply from aaa.bbb.ccc.ddd: bytes=..." to "Request timed out." (or the other way around). The last value that had a ping answers is the MTU of your internet connection. More about the subject here: MTU Size Issues | Network World

 

[Easy Rhino]

There was updated drives for Wi-FI 1.0.2.52SF vs 1.0.2.53SF(-KF)/1.0.2.54. So...

Hmm, thanks for checking that. maybe I was mistaken on my old build and it was the .52 version I had. Because I had another hiccup two days ago where I couldn't connect to 5ghz again. Changing channels (again) seemed to fix it... but maybe I should try rolling back to .52 and see if I have any problems over several days.

 

[Soluna]

A friend of mine just got the R7800 today and I just want to thank you and your team for keeping the firmware up to date, fixing bugs, and much more!

 

[Deleted member 22229]

Hi Voxel. I see Netgear just released a new firmware 1.0.2.58 for the 7800 will you be making a new build based on this any time soon ? As always Thanks for your work.

 

[microchip]

I just installed the official .58. No issues at all at first glance

 

[Voxel]

Hi Voxel. I see Netgear just released a new firmware 1.0.2.58 for the 7800 will you be making a new build based on this any time soon ? As always Thanks for your work.

Yes, sure. As soon as they publish GPL codes of this version. Now it is not available even in binary form (only from GUI of router). This page:

https://www.netgear.com/support/product/r7800.aspx#download

still suggests to download 1.0.2.52.

Voxel.