I bought a Nighthawk X6 R8000 router (Firmware Version V1.0.4.76_10.1.82) for my domestic use.
I've a raspberry PI, a NAS (with 2 ethernet connections), and a smart tv connected to the LAN and two desktop computers, a laptop plus a few random devices connected to the WLAN. Desktop computers are generally connected to the high frequency band (5G-2) although one of them doesn't seem to see its SSID for some reasons, so it's connected to the hybrid (5G-1) band with one OS. Both the desktop PCs are on LOS from the router, with no walls between them.
Everything seemed to work fine at first, then I noticed that I kept receiving occasional DNS_PROBE_FINISHED_NXDOMAIN errors when navigating. This error disappears when I refresh the page. I'm not sure if this problem is only related to the WLAN as I can't propetly test it connecting a computer to the LAN due to the awkward position of the router.
I tried to switch to OpenDNS and GoogleDNS to no avail. During my tests I've also noticed a weird thing. If I ping the router from one of my desktop PC I have this latency:
$ ping 192.168.1.1
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
64 bytes from 192.168.1.1: icmp_seq=1 ttl=64 time=3.74 ms
64 bytes from 192.168.1.1: icmp_seq=2 ttl=64 time=2.35 ms
64 bytes from 192.168.1.1: icmp_seq=3 ttl=64 time=6.19 ms
64 bytes from 192.168.1.1: icmp_seq=4 ttl=64 time=2.11 ms
64 bytes from 192.168.1.1: icmp_seq=5 ttl=64 time=1.95 ms
64 bytes from 192.168.1.1: icmp_seq=6 ttl=64 time=1.93 ms
64 bytes from 192.168.1.1: icmp_seq=7 ttl=64 time=1.88 ms
64 bytes from 192.168.1.1: icmp_seq=8 ttl=64 time=2.55 ms
64 bytes from 192.168.1.1: icmp_seq=9 ttl=64 time=1.85 ms
64 bytes from 192.168.1.1: icmp_seq=10 ttl=64 time=3.28 ms
64 bytes from 192.168.1.1: icmp_seq=11 ttl=64 time=1.86 ms
64 bytes from 192.168.1.1: icmp_seq=12 ttl=64 time=2.49 ms
64 bytes from 192.168.1.1: icmp_seq=13 ttl=64 time=2.69 ms
64 bytes from 192.168.1.1: icmp_seq=14 ttl=64 time=1.88 ms
64 bytes from 192.168.1.1: icmp_seq=15 ttl=64 time=3.23 ms
64 bytes from 192.168.1.1: icmp_seq=16 ttl=64 time=1.85 ms
64 bytes from 192.168.1.1: icmp_seq=17 ttl=64 time=2.55 ms
64 bytes from 192.168.1.1: icmp_seq=18 ttl=64 time=6.10 ms
64 bytes from 192.168.1.1: icmp_seq=19 ttl=64 time=6.36 ms
64 bytes from 192.168.1.1: icmp_seq=20 ttl=64 time=2.70 ms
64 bytes from 192.168.1.1: icmp_seq=21 ttl=64 time=3.23 ms
64 bytes from 192.168.1.1: icmp_seq=22 ttl=64 time=2.45 ms
64 bytes from 192.168.1.1: icmp_seq=23 ttl=64 time=2.40 ms
64 bytes from 192.168.1.1: icmp_seq=24 ttl=64 time=2.84 ms
64 bytes from 192.168.1.1: icmp_seq=25 ttl=64 time=3.49 ms
64 bytes from 192.168.1.1: icmp_seq=26 ttl=64 time=2.35 ms
64 bytes from 192.168.1.1: icmp_seq=27 ttl=64 time=2.54 ms
64 bytes from 192.168.1.1: icmp_seq=28 ttl=64 time=6.27 ms
64 bytes from 192.168.1.1: icmp_seq=29 ttl=64 time=1.82 ms
^C
--- 192.168.1.1 ping statistics ---
29 packets transmitted, 29 received, 0% packet loss, time 28043ms
rtt min/avg/max/mdev = 1.820/2.996/6.355/1.391 ms
To me having 3ms of avg in WLAN pinging the intranet is weird, but what got me thinking is the 6ms of ping spike. If I connect to my NAS through ssh and ping the router from there (so a LAN ping) here's what I get:
$ sudo ping 192.168.1.1
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
64 bytes from 192.168.1.1: icmp_seq=1 ttl=64 time=0.363 ms
64 bytes from 192.168.1.1: icmp_seq=2 ttl=64 time=0.255 ms
64 bytes from 192.168.1.1: icmp_seq=3 ttl=64 time=0.296 ms
64 bytes from 192.168.1.1: icmp_seq=4 ttl=64 time=0.274 ms
64 bytes from 192.168.1.1: icmp_seq=5 ttl=64 time=0.294 ms
64 bytes from 192.168.1.1: icmp_seq=6 ttl=64 time=0.322 ms
64 bytes from 192.168.1.1: icmp_seq=7 ttl=64 time=0.401 ms
64 bytes from 192.168.1.1: icmp_seq=8 ttl=64 time=0.319 ms
64 bytes from 192.168.1.1: icmp_seq=9 ttl=64 time=0.304 ms
[...]
64 bytes from 192.168.1.1: icmp_seq=84 ttl=64 time=0.287 ms
64 bytes from 192.168.1.1: icmp_seq=85 ttl=64 time=0.394 ms
64 bytes from 192.168.1.1: icmp_seq=86 ttl=64 time=0.242 ms
64 bytes from 192.168.1.1: icmp_seq=87 ttl=64 time=0.341 ms
64 bytes from 192.168.1.1: icmp_seq=88 ttl=64 time=0.236 ms
64 bytes from 192.168.1.1: icmp_seq=89 ttl=64 time=0.288 ms
64 bytes from 192.168.1.1: icmp_seq=90 ttl=64 time=0.415 ms
64 bytes from 192.168.1.1: icmp_seq=91 ttl=64 time=0.240 ms
64 bytes from 192.168.1.1: icmp_seq=92 ttl=64 time=0.413 ms
64 bytes from 192.168.1.1: icmp_seq=93 ttl=64 time=0.289 ms
64 bytes from 192.168.1.1: icmp_seq=94 ttl=64 time=0.339 ms
64 bytes from 192.168.1.1: icmp_seq=95 ttl=64 time=0.649 ms
64 bytes from 192.168.1.1: icmp_seq=96 ttl=64 time=0.456 ms
64 bytes from 192.168.1.1: icmp_seq=97 ttl=64 time=0.295 ms
64 bytes from 192.168.1.1: icmp_seq=98 ttl=64 time=0.299 ms
64 bytes from 192.168.1.1: icmp_seq=99 ttl=64 time=0.322 ms
64 bytes from 192.168.1.1: icmp_seq=100 ttl=64 time=0.297 ms
64 bytes from 192.168.1.1: icmp_seq=101 ttl=64 time=0.359 ms
64 bytes from 192.168.1.1: icmp_seq=102 ttl=64 time=0.393 ms
64 bytes from 192.168.1.1: icmp_seq=103 ttl=64 time=0.316 ms
64 bytes from 192.168.1.1: icmp_seq=104 ttl=64 time=0.279 ms
64 bytes from 192.168.1.1: icmp_seq=105 ttl=64 time=0.297 ms
64 bytes from 192.168.1.1: icmp_seq=106 ttl=64 time=0.402 ms
64 bytes from 192.168.1.1: icmp_seq=107 ttl=64 time=0.295 ms
64 bytes from 192.168.1.1: icmp_seq=108 ttl=64 time=0.272 ms
64 bytes from 192.168.1.1: icmp_seq=109 ttl=64 time=0.289 ms
64 bytes from 192.168.1.1: icmp_seq=110 ttl=64 time=0.317 ms
64 bytes from 192.168.1.1: icmp_seq=111 ttl=64 time=0.380 ms
64 bytes from 192.168.1.1: icmp_seq=112 ttl=64 time=0.294 ms
64 bytes from 192.168.1.1: icmp_seq=113 ttl=64 time=0.412 ms
64 bytes from 192.168.1.1: icmp_seq=114 ttl=64 time=0.260 ms
64 bytes from 192.168.1.1: icmp_seq=115 ttl=64 time=0.364 ms
64 bytes from 192.168.1.1: icmp_seq=116 ttl=64 time=0.294 ms
64 bytes from 192.168.1.1: icmp_seq=117 ttl=64 time=0.245 ms
64 bytes from 192.168.1.1: icmp_seq=118 ttl=64 time=0.342 ms
64 bytes from 192.168.1.1: icmp_seq=119 ttl=64 time=0.257 ms
64 bytes from 192.168.1.1: icmp_seq=120 ttl=64 time=0.298 ms
64 bytes from 192.168.1.1: icmp_seq=121 ttl=64 time=0.411 ms
64 bytes from 192.168.1.1: icmp_seq=122 ttl=64 time=0.297 ms
64 bytes from 192.168.1.1: icmp_seq=123 ttl=64 time=0.399 ms
64 bytes from 192.168.1.1: icmp_seq=124 ttl=64 time=0.256 ms
64 bytes from 192.168.1.1: icmp_seq=125 ttl=64 time=0.199 ms
64 bytes from 192.168.1.1: icmp_seq=126 ttl=64 time=0.300 ms
64 bytes from 192.168.1.1: icmp_seq=127 ttl=64 time=0.291 ms
64 bytes from 192.168.1.1: icmp_seq=128 ttl=64 time=0.256 ms
64 bytes from 192.168.1.1: icmp_seq=129 ttl=64 time=0.299 ms
64 bytes from 192.168.1.1: icmp_seq=130 ttl=64 time=7.83 ms
64 bytes from 192.168.1.1: icmp_seq=131 ttl=64 time=0.315 ms
64 bytes from 192.168.1.1: icmp_seq=132 ttl=64 time=0.258 ms
[...]
64 bytes from 192.168.1.1: icmp_seq=436 ttl=64 time=0.480 ms
64 bytes from 192.168.1.1: icmp_seq=437 ttl=64 time=0.253 ms
64 bytes from 192.168.1.1: icmp_seq=438 ttl=64 time=0.314 ms
64 bytes from 192.168.1.1: icmp_seq=439 ttl=64 time=0.249 ms
64 bytes from 192.168.1.1: icmp_seq=440 ttl=64 time=0.324 ms
64 bytes from 192.168.1.1: icmp_seq=441 ttl=64 time=0.253 ms
64 bytes from 192.168.1.1: icmp_seq=442 ttl=64 time=0.278 ms
64 bytes from 192.168.1.1: icmp_seq=443 ttl=64 time=0.410 ms
64 bytes from 192.168.1.1: icmp_seq=444 ttl=64 time=0.247 ms
64 bytes from 192.168.1.1: icmp_seq=445 ttl=64 time=0.315 ms
64 bytes from 192.168.1.1: icmp_seq=446 ttl=64 time=0.296 ms
64 bytes from 192.168.1.1: icmp_seq=447 ttl=64 time=0.297 ms
64 bytes from 192.168.1.1: icmp_seq=448 ttl=64 time=0.315 ms
64 bytes from 192.168.1.1: icmp_seq=449 ttl=64 time=0.297 ms
64 bytes from 192.168.1.1: icmp_seq=450 ttl=64 time=0.248 ms
64 bytes from 192.168.1.1: icmp_seq=451 ttl=64 time=0.295 ms
64 bytes from 192.168.1.1: icmp_seq=452 ttl=64 time=0.319 ms
64 bytes from 192.168.1.1: icmp_seq=453 ttl=64 time=0.296 ms
^C
--- 192.168.1.1 ping statistics ---
453 packets transmitted, 453 received, 0% packet loss, time 486ms
rtt min/avg/max/mdev = 0.188/0.343/7.827/0.363 ms
essentially, 7ms of ping spike on LAN.
Now, the ping spike is concerning to me but it's not a real problem. What I find troublesome is the failure to resolve the DNS in some occasions and, most importantly, I wish to know if there is a problem with the router.
Do you think that my router is broken (I'm still on time to send it back)? Is this a known firmware problem?
Re: Nighthawk X6 R8000 ping spikes and DNS problems
By revert back you mean return the router?
What I had before was the stock router from my ISP which is...well....not that good.
I bought this router on a solid deal, my options now are troubleshoting these issues, return the router and roll the dices again on a new one or wait for a fix from NETGEAR (assuming it's indeed a FW problem and not an HW problem).
Re: Nighthawk X6 R8000 ping spikes and DNS problems
Maybe I was unclear. The problem is not finding a nice and tidy list of all possible firmwares for my model.
The problems are to (1) enstabilish that this is a FW problem and not an HW problem, and in that case (2) find the FW which (i) solves all my problems and (ii) doesn't introduce new problems and (iii) it doesn't have security holes (it's still an outdated FW).
As for (1) my hope was that giving enough details of my problem and my configuration someone could recognise the problem as a common one or spot come criticities in my configuration or suggest some targeted tests.
As for (2) ideally I'd like to know the most stable version of the FW that people generally use with the least complains/issues. If this is known.
Re: Nighthawk X6 R8000 ping spikes and DNS problems
It's connected to an Openreach (BT) Huawei 4-port modem. It's worth noting that I was using a BT stock wifi router before I switched over this NG one. I swtiched over this NG router around the same time I upgraded my NAS to a new model (I'm adding this info just in case it's relevant).
I didn't had these issues with the previous BT wfi router (I had others, mostly in terms of latency and coverage, heve the upgrade to a better router).
So, the DNS problems are likely to be related to the latest version of the FW. Do you think that the strange behaviour of the ping spikes are concerning and/or related to the FW as well?
Re: Nighthawk X6 R8000 ping spikes and DNS problems
Is the modem just a modem only or is there a built in router at the modem? Sometimes, 4 ports on a modem can inidicate having a built in router.
Testing pings will need to be done with a wired PC and connected to the ISP modem first to see if there are any issues there using pingplotter.com test sofware. Then connected with a wired PC with the R series router online. If the ISP modem is just a modem.
As suggested though, there are known issues with recent FW on the NG router. So you'll need to downgrade FW.
Re: Nighthawk X6 R8000 ping spikes and DNS problems
Yes, but even if BT is a router, the sole thing connected to it is the NG router. The pings I've performed are a WLAN and a LAN ping to the NG router directly, not external. These are NG intranet pings so the packets shouldn't have been transmitted to the BT modem/router at all, amirite?
Re: Nighthawk X6 R8000 ping spikes and DNS problems
Almost nothing else in both tests. But again, the ping spikes are more a curiosity rathern than a problem. I'll try to downgrade the FW in inverse chronological order until the problem is solved.
Re: Nighthawk X6 R8000 ping spikes and DNS problems
I have the exact issues you have noted...again...still. Even replying to this community thread gives me a DNS resolution error and slow response time. I previously upgraded my firmware from V1.0.4.68_10.1.75 to 82 a couple months ago and immediately had brand new DNS resolution errors. I have Spectrum as my provider. I reverted back to my old firmware version, and the issues went away. Please NG fix this issue! To restore older versions of firmware...
Re: Nighthawk X6 R8000 ping spikes and DNS problems
It shouldn't touch your configs. Firmware in general is much lower layer than higher layer software edits. Good luck. DNS has been around since I graduated high school in 1983 and developers still can't get it right. Grr. Hope it get's fixed soon.
