NETGEAR is aware of a growing number of phone and online scams. To learn how to stay safe click here.
Forum Discussion
Nighthawk X6 R8000 ping spikes and DNS problems
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?
18 Replies
There are known issues with the 8000 series FW. Best to revert back to what had been working until NG fixes this.
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).
No, revert back FW version to what had been working before you updated the FW.
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...
Go to this site to download: https://www.netgear.com/support/product/r8000.aspx#download
It's not intuitive, but look for the big + sign that say view previous versions.
