Build for Netgear R7800

To go to stock you need turn off the router then put a pin in the reset hole and press it, turn on the power with pin still pressed and wait for the router's power LED to start flashing white, now take off the pin. Then set your PC's IP address to 192.168.1.2 and gateway setting to 192.168.1.1 then open Command Prompt and type "tftp -i 192.168.1.1 put firmware-file-name". The router will transfer the image file and should eventually boot to stock. Your previous stock netgear settings are saved so you won't need to setup everything again.

I typically update the first message of this thread when there is a new version.

One last question. If I'm running this LEDE build and a new version comes out, do I upgrade by doing a web flash from LuCi with the *.sysupgrade.tar file?

Thanks for the info

Quite normal sysupgrade, either from LuCi or from console

My confusion is because that I thought sysupgrade usually worked on bin files and it seems that your sysupgrade file is a tar file. Do I need to rename the file before running the command?

The sysupgrade file name depends on the target. Ipq806x has different format than e.g. ar71xx

How is wifi now on builds from master? Holding off for fear of upsetting the users (wife and kids!)

1 Like

@hnyman I suppose itā€™s good to include into your builds


That memory leak seem to be the root cause of rx buffer corruption happening

I have included it in the new test build
lede-r4751-4b3ffecf2b-20170828-ath10k-rxring-test

Hopefully that fix would help people suffering from bad wireless performance. (My own wireless usage is rather modest, so the unpatched wifi driver has worked well enough for me.)

While this patch may have improved wi-fi performance it has not fixed a much more annoying problem : MAC errors which were reported a few days ago by another poster.

Current Build and Kernel Versions:
root@R7800RT1:~# cat /etc/os-release|grep -i build
BUILD_ID="r4751-4b3ffecf2b"
root@R7800RT1:~# cat /proc/version
Linux version 4.9.44 (perus@ub1704) (gcc version 5.4.0 (LEDE GCC 5.4.0 r4694-e7373e489d) ) #0 SMP Mon Aug 28 15:06:37 2017

The MAC problem is easily reproduced by wireless connecting a pc to the R7800 router on either the 2.4 GHz or 5 GHz radios and establishing an SSH terminal session.

Enter the following syntax at the CLI:
root@R7800RT1:~# tree /

A partial directory tree structure is displayed followed by the message:
Corrupted MAC on input.
ssh_dispatch_run_fatal: Connection to 192.168.16.1 port 22: message authentication code incorrect

The SSH session is then terminated.

The r3496 and r3498 builds don't have the problem but the r4707, r4723, and r4751 builds do.

  • Magnetron1.1

Hi is this fix ring buffer patch added to 3498 build?

No. the 17.01 branch build is unpatched.

I briefly tested that earlier today and it worked perfectly. tree was fully printed to the console.

Do you have a reference to the earlier report of a MAC problem? I couldn't find any posts with R7800 and MAC errors.

If the problem would have been in all latest trunk builds and would affect all users, I guess there would have been more reports by now.

OK thanks! :smiley:

Actually I experience similarly looking issue - 2.4 ghz for me produces corrupted frames that are not corrected by error correction mechanisms and that may (among others) result in the behavior explained by @Magnetron1.1
I donā€™t know when Iā€™ve started experiencing it because I donā€™t use 2.4ghz mostly.
5GHz is perfectly fine for me.

edit: hmm, the only difference I have between bands is that 5GHz band has 802.11w enabled. @Magnetron1.1 could you enable it and verify the result? Maybe itā€™s hostapd bugging after all.

edit2: or perform the test with encryption disabled

@hnyman

Here's LuisGC Jul 19 post on this thread:

"Well, I'm having a strange issue which I cannot seem to understand.
When I access some remote server (with ssh, rsync, scp, ...) and push the connection a little bit (either by using X forwarding and opening some windows or doing a transfer), my connection drops with a "incorrect MAC" error message or something to that effect (where MAC is Message Authentication Code, as I've learned). From what I could gather, it seems that something in the chain corrupts the message and then I get disconnected. This happens with any PC I connect via WiFi and as I'm able to establish a connection I discarded the possibility of out of date OpenSSH and mismatch of MAC ciphers causing the issue. Also, connecting with the cable seems to work fine and I do not get a connection drop.
I can't even manage to clone the lede git repo, for instance, as the connection drops halfway.

Any suggestions? Or I'm the only one affected?
This happens with both the 'lede1701-r3458-74d5c3e019-20170711' and 'lede-r4561-254f0da6d2-20170712' builds."

I still have no problem duplicating this error with a wireless connection. Error does not occur on a wired connection.

I tried to trigger the MAC problem with 2.4 GHz band without success. No visible bug.

I cloned LEDE git repo five times in a row etc., ran "tree /" on router console at the same time, but no indication of error.

I then burdened the connection with flent RRUL testing (about 100 Mbit/s traffic load), and repeated the git cloning and tree. Still everything ok.

I have otherwise vanilla wifi settings (channel 3, HT20), but I use 802.11r

It happens also with the stable 17.01 branch? That would suggest that it either a rather old bug, or it is related to the wifi firmware calibration table reading fix in master and in my 17.01 build (but not in the official 17.01 repo). You might test with an official release build from the 17.01 branch, like 17.01.2 and see if it happens with that.

As far as I remember Iā€™ve had alike problem with corrupted frames even before the calibration fix - that was the trigger if I recall correctly to try to fix the calibration with chunkeey, but still worths a try

edit: btw it doesnā€™t correlate with this

While still running hnyman's r4751 build, I disabled all security on the 5GHz radio and reran the test and in a matter of seconds the MAC error occurred. I re-enabled security (PSK2-Personal/AES) and set 802.11w Management Frame Protection = optional. The MAC errors still occurred. Setting the 802.11w Management Frame Protection = required, will not allow any of the wi-fi adapters to associate with the 5GHz radio.

At this point I re-installed the wpad package which includes hostapd (opkg files wpad ) ( opkg --force-reinstall install wpad ) and performed all the above steps and the results were the same.

Reloaded hnyman's r3498 build and the MAC errors are gone ( security PSK2-Personal/AES 802.11w Management Frame Protection = disabled ). When I have the time, I'll try the "official" LEDE builds and report back.

@hnyman surprise! your r3498 build comes with nlbwmon monitor :smiley: so nice!. thanks for that!.