What's new

Netgear Firmware Update for X4S R7800 (1.0.2.40)

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

AntonK

Very Senior Member
Release notes and firmware here

Bug Fixes:
  • Fixes the issue where the access control feature can't be disabled when the R7800 is in AP mode.
  • Fixes the issue where the ReadySHARE page, accessed from the BASIC tab, shows a "No such file or directory error" message.
  • Fixes the issue where the Robocopy command can't perform a USB performance test.
  • Fixes an issue where the max value of the traffic meter's WAN traffic counter is limited to 4G.
  • Fixes security issues.
  • Fixes minor bugs.
Known unfixed issues:

  • Intel7260/3160 has a connection problem with the R7800 when the HT160 is enabled. This issue is due to the Intel driver. Intel is looking into this.
 
Release notes and firmware here

Bug Fixes:
  • Fixes the issue where the access control feature can't be disabled when the R7800 is in AP mode.
  • Fixes the issue where the ReadySHARE page, accessed from the BASIC tab, shows a "No such file or directory error" message.
  • Fixes the issue where the Robocopy command can't perform a USB performance test.
  • Fixes an issue where the max value of the traffic meter's WAN traffic counter is limited to 4G.
  • Fixes security issues.
  • Fixes minor bugs.
Known unfixed issues:

  • Intel7260/3160 has a connection problem with the R7800 when the HT160 is enabled. This issue is due to the Intel driver. Intel is looking into this.
Noticed that if you do a manual reset on this and then add your own wifi password you get a
'400 Bad Request -Server does not support operation'
its okay if you change the network names but the wifi throws that error up. In fact changing many setting seems to cause that error or a blank screen sometimes like in QoS for some devices say iPad but not a TV. I went back to 1.0.2.38 and none of these issues appear. This new firmware seems really broken.

Well I reset the router yet again after updating to 1.0.2.40 and same issues, 400 Bad Request -Server does not support operation if you try to change the password, tried other browsers even my ipad and its the same so its not the router or my iMac. Went back down to 1.0.2.38 with a hard reset and all is well. This firmware is borked on my end and I have no idea why. Also you just get blank pages trying to change QoS on some devices but not others, what Netgear have done this time. <sigh>
 
Last edited:
So far FW has been stable, seen no issues with it
Tried it on two macs same issue. Not sure if it’s specific to macOS but if the router is hard reset you cannot enter a new WiFi password using Firefox 57.02 Safari 11 on 10.13.2 and an iPad up to date on 11.2.1. You just get that server error no matter what changing WiFi password but not the ssid. Also changing QoS settings brings up random blank pages. The fact if you downgrade to 1.0.2.38 and it all works fine would indicate 1.0.2.40 having issues. It would be odd to have both iOS and macOS having the same bug with the router. It’s possible Of course there has been issues that effect Apple and iOS before.
 
Last edited:
"It works for me" is not always helpful, but it can mean there is something not quite right somewhere if things can work for others.

I am new to Netgear wireless routers, so I am playing it safe for now. My recently purchased R7800 had 1.0.2.36 installed which I immediately upgraded to 1.0.2.38 after configuring it to my liking. No reset was performed after the upgrade. 1.0.2.40 was released, so I upgraded and again did not perform a manual reset. Everything is working just fine as is, plus Comcast is graciously giving me twice the bandwidth since I reset my cablemodem (to accommodate the different mac address of the R7800) and therefore, I do not want to ruin a good thing. :)
 
"It works for me" is not always helpful, but it can mean there is something not quite right somewhere if things can work for others.

I am new to Netgear wireless routers, so I am playing it safe for now. My recently purchased R7800 had 1.0.2.36 installed which I immediately upgraded to 1.0.2.38 after configuring it to my liking. No reset was performed after the upgrade. 1.0.2.40 was released, so I upgraded and again did not perform a manual reset. Everything is working just fine as is, plus Comcast is graciously giving me twice the bandwidth since I reset my cablemodem (to accommodate the different mac address of the R7800) and therefore, I do not want to ruin a good thing. :)
While I agree, its odd that (having updated via the router interface this time) exactly the same issues with QoS are occurring.
Android TV is now on low priority, PS4 Pro gaming console is now on Low priority, before both were high and now you cant change them just as before when I tried version 1.0.2.40. If I go to change them I get a blank screen when I press apply and nothing happens. The same with the Satellite STB, all this worked fine on 1.0.2.38. Yet other devices, once again exactly the same ones I tried the last three times all update just fine in QoS.

This has to be firmware related, maybe just on Macs and iOS devices running High Sierra and iOS 11? Its happened to many times (four to be exact) and to just the same devices so beyond a coincidence which is odd to say the least. Also its effecting single threaded speed tests, single threads are slower than multi, both should roughly be the same, and yes no issue with 1.0.2.38 on these speed tests. <sigh>
 
Last edited:
Well I finally found out what the issue was. in 1.0.2.40 you cant have a 63 digit ASCII character password, but you can have a 62 digit one, and then QoS works as it should :confused: I know not many people use full length passwords but I have always, and tbh how can Netgear mess that up when it clearly says you can use 63 ASCII characters in wifi settings :rolleyes: So I had to alter all my device passwords this morning. I now need lots of coffee.
 
I would have had the same problem as my password is also the max number of characters.
QoS still behaves oddly with blank pages though even with a shorter password, I'm sticking to the .38 variant for now :( actually Voxels version. I have no faith in Netgear code at all.
 
Last edited:
Voxel's v44SF is very stable and solid. Best version since .38 IMO.

QoS still behaves oddly with blank pages though even with a shorter password, I'm sticking to the .38 variant for now :( actually Voxels version. I have no faith in Netgear code at all.
 
Voxel's v44SF is very stable and solid. Best version since .38 IMO.
I agree, it is. Although it does not help that I think Netgear did not release the GPL source code for 1.0.2.40 and it fixes I belive three Stack overflows. Also firmware should never be released like this, many people use stock and don't know of Voxels work.
I see the R9000 is now for some having the same '400 Bad Request' issues as well on the Netgear forums, so some new bug introduced in the recently released firmware. Also until the GPL code is released (if it hasn't been yet) its hard to know if Voxel closed the cross site vulnerabilities as there are parts of the firmware he cannot reach, but I have faith in his knowledge about such things.
Stock firmware should not be released that cant use a 63 ASCII because it wont let you enter one without a 400 server error (If you hard reset after updating) but the router works fine if you install with no reset while using a 63 ASCII wifi password, however that then breaks QoS with more blank pages with 400 server errors and keeps pretty much all devices stuck on low, like smart TV's and Game consoles. Also there is an issue with single threaded speeds on 1.0.2.40 firmware, it could be coincidence of course but I would need two R7800's to test that against Voxels and I have had enough of playing the firmware merry-go-round at the moment with my own device.
 
Last edited:
Ya, all thats nice however Mfrs have never been too keen on releasing FW with out bugs. Each build presents it's own issues at times. NG has been one of the worst to do fixes or come out with releases to fix things as they should be. I had the R9000 as a demo. QoS was missing for a long time. Not sure if it ever got implemented correctly.

Something like this regarding vulnerabilities and GPL, if you find issues, needs to be posted here:
https://community.netgear.com/t5/Nighthawk-WiFi-Routers/bd-p/home-wifi-routers-nighthawk

I don't know if NG watches SNB forums as much as there own forums. So users should to post there also for better coverage.

Voxel's FW is better maintained and he usually tries to keep some of the back end code better up to date if he has the ability and resources to do it and if it's in GPL. Ive found better operation and performances with his FW on NG routers.

He watches this forum and this one:
https://www.myopenrouter.com/forum

His repo is here:
https://www.voxel-firmware.com/Downloads/Voxel/html/r7800.html

You don't need two r7800s to work and test with Voxels FW.

I agree, it is. Although it does not help that I think Netgear did not release the GPL source code for 1.0.2.40 and it fixes I belive three Stack overflows. Also firmware should never be released like this, many people use stock and don't know of Voxels work.
I see the R9000 is now for some having the same '400 Bad Request' issues as well on the Netgear forums, so some new bug introduced in the recently released firmware. Also until the GPL code is released (if it hasn't been yet) its hard to know if Voxel closed the cross site vulnerabilities as there are parts of the firmware he cannot reach, but I have faith in his knowledge about such things.
Stock firmware should not be released that cant use a 63 ASCII because it wont let you enter one without a 400 server error (If you hard reset after updating) but the router works fine if you install with no reset while using a 63 ASCII wifi password, however that then breaks QoS with more blank pages with 400 server errors and keeps pretty much all devices stuck on low, like smart TV's and Game consoles. Also there is an issue with single threaded speeds on 1.0.2.40 firmware, it could be coincidence of course but I would need two R7800's to test that against Voxels and I have had enough of playing the firmware merry-go-round at the moment with my own device.
 
Last edited:
I agree, it is. Although it does not help that I think Netgear did not release the GPL source code for 1.0.2.40 and it fixes I believe three Stack overflows. ... Stock firmware should not be released that cant use a 63 ASCII because it wont let you enter one without a 400 server error (If you hard reset after updating) but the router works fine if you install with no reset while using a 63 ASCII wifi password, however that then breaks QoS with more blank pages with 400 server errors and keeps pretty much all devices stuck on low, like smart TV's and Game consoles. Also there is an issue with single threaded speeds on 1.0.2.40 firmware, it could be coincidence of course but I would need two R7800's to test that against Voxels and I have had enough of playing the firmware merry-go-round at the moment with my own device.

In addition to the problems listed above, version 1.0.2.40 also suffers from blank response screens when you try to update device information. Like the QoS problem noted above, the changes are not made. While I am pleased that Netgear is finally patching security vulnerabilities on a more regular basis, it is hard for me to believe that their Q&A apparently does not check basic data entry on all the screens.

Other than the problems noted above, v. 1.0.2.40 has been stable for me, and throughput in multi-stream TCP wired and wireless tests is as good as previous releases.
 
In addition to the problems listed above, version 1.0.2.40 also suffers from blank response screens when you try to update device information. Like the QoS problem noted above, the changes are not made. While I am pleased that Netgear is finally patching security vulnerabilities on a more regular basis, it is hard for me to believe that their Q&A apparently does not check basic data entry on all the screens.

Other than the problems noted above, v. 1.0.2.40 has been stable for me, and throughput in multi-stream TCP wired and wireless tests is as good as previous releases.
Have you tested single threaded speeds with 1.0.2.40? Multi threaded was fine here so trying to rule out backhaul with my isp.
 
Ya, all thats nice however Mfrs have never been too keen on releasing FW with out bugs. Each build presents it's own issues at times. NG has been one of the worst to do fixes or come out with releases to fix things as they should be. I had the R9000 as a demo. QoS was missing for a long time. Not sure if it ever got implemented correctly.

Something like this regarding vulnerabilities and GPL, if you find issues, needs to be posted here:
https://community.netgear.com/t5/Nighthawk-WiFi-Routers/bd-p/home-wifi-routers-nighthawk

I don't know if NG watches SNB forums as much as there own forums. So users should to post there also for better coverage.

Voxel's FW is better maintained and he usually tries to keep some of the back end code better up to date if he has the ability and resources to do it and if it's in GPL. Ive found better operation and performances with his FW on NG routers.

He watches this forum and this one:
https://www.myopenrouter.com/forum

His repo is here:
https://www.voxel-firmware.com/Downloads/Voxel/html/r7800.html

You don't need two r7800s to work and test with Voxels FW.
The reason I said two was to single out my single threaded speed issues. I wanted to know if Netgear made a mistake vs voxels working well. The fact the GPL for 1.0.2.40 is not released is a pain as nobody knows what they changed. Right now I’m using voxels but swapping routers over with one having stock would help me verify isp backhaul not netgear firmware. As to the vulnerabilities mentioned they are fixed in 1.0.2 .40 nothing needs reporting Netgear has fixed those (I imagine Voxel has to but there are areas even he sadly can’t get to) netgear should employ him really.
 
Well, you could find a used r7800 some place if you really wanted too.

Ya, would be a nice addition to there FW development team. Also would be nice to have a better QA testing process and team as well. o_O

The reason I said two was to single out my single threaded speed issues. I wanted to know if Netgear made a mistake vs voxels working well. The fact the GPL for 1.0.2.40 is not released is a pain as nobody knows what they changed. Right now I’m using voxels but swapping routers over with one having stock would help me verify isp backhaul not netgear firmware. As to the vulnerabilities mentioned they are fixed in 1.0.2 .40 nothing needs reporting Netgear has fixed those (I imagine Voxel has to but there are areas even he sadly can’t get to) netgear should employ him really.
 
Wonder why @NetgearGUY hasn’t chimed in on any of this, seeing how he has connections at Netgear and could pass this info in, and get it addressed in a timely manner.
 
I believe he's chimed in on a different thread. ;)
 
Wonder why @NetgearGUY hasn’t chimed in on any of this, seeing how he has connections at Netgear and could pass this info in, and get it addressed in a timely manner.
I contacted him via PM as well a while back when I found this bug in stock. :)
 
Last edited:
Have you tested single threaded speeds with 1.0.2.40? Multi threaded was fine here so trying to rule out backhaul with my isp.

I have no good way to run a single stream TCP test to my local ISP. While I can run DSL Reports single stream tests, all of their servers have Round Trip Times (RTT) to my location on the order of 10's of milliseconds with some packet losses reported.

Very small amounts of packet loss with RTT's on the order of 10's of msec can destroy TCP throughput. For example with a RTT=30 msec, delayed ACKs, and a probability of a lost TCP segment of 1e-05 (i.e., 10 lost packets in a million), the Mathis equation predicts a maximum TCP throughput in steady-state of only 107 Mbps -- so much for the 1 Gbps connection to my ISP. There is a great experimental example of what happens to TCP throughput with a bad 10 Gbps line card resulting in a lost packet rate of one packet in 22,000 at the following URL: https://fasterdata.es.net/network-tuning/tcp-issues-explained/packet-loss/.

The bottom line is that to make accurate measurements of TCP router throughput, you need RTT's of a few msec and links that are essentially error free. Setting up a test environment like that used in the SNB router tests is the best approach to make these kinds of measurements.The newer SNB HTTP throughput tests are also eye-opening on real world router performance, and are the weakest area of the R7800's performance BTW.
 

Latest threads

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top