Should I RMA my n66u?

Associate
Joined
8 Jul 2010
Posts
863
Location
Staffordshire
For the past month and a half I've had issues with my home network. The problems started around the time that I got my new router, an Asus n66u, so naturally I thought it was the cause. So, seen as though the most common issue was with the stability and speed of the wireless signal, I did a bit of research and found that the Asus firmware version I was using had stability issues. So I updated to the latest version but I was still getting connection problems. Although, they seemed to be a little less regular. Then my modem kicked the bucket and after getting it replaced, the problems seemed to be gone... but that didn't last. A few days of connectivity and now I'm back to this-



All in all the result is pretty typical apart from the ping which is usually above the 1000ms mark. I've tried numerous different servers. I've tried connecting using different Ethernet cables (that have never shown any signs of being faulty) and I've tried connecting wirelessly but nothing makes a difference. Only after I've power cycled both the modem and router can I get full speed and at the moment it'll last for a few minutes. But, other times it'll last for a day or two, and then the issue rears it's ugly head again.

I've tried to eliminate all the possible causes (firmware, cables, three different computers, the modem and my ISP) but I've been unable to fix the problem. So I'm considering RMA. Before I do though, I'd like to know whether there's anything else I can do?... I'm also worried due to the the intermittent nature of the fault, it might still pass an RMA inspection.


[NOTE] I'm switching ISP in a couple of weeks time. Would it be wise to wait until I've switched so I can categorically rule out my current ISP and their equipment?
 
Virgin media cable modem service?

Remove the router from the equation. Connect a PC to the VM router/modem. Do you have the same issues?
 
Virgin media cable modem service?

Remove the router from the equation. Connect a PC to the VM router/modem. Do you have the same issues?

I had tried that but the issue didn't arise... there's nothing more frustrating than a completely random, intermittent problem. I tried it again though and I've just had my ping jump well above the 2000ms mark!... oddly enough, that ping was through the command console but when I tried speedtest.net, I got a mid 30's ping but abysmal speed. I'll carry on using just the superdud (burn, take that Virgin Media!) just to make sure and to save having to also reset the n66u each time.

I guess I'll get a definitive answer when I jump ship to Plusnet.
 
The wireless laptop just lost the superhub connection, or rather it said it was connected, I could login into the superhub but it just wouldn't load any webpage at all. No matter what browser I used or how many times I reset the hub. So it's back to the n66u for wireless and the superhub is in modem mode... you know what, I'm sick of calling it the "superhub". From now on I'm calling it the turdball. It's my belief that the turdball is at fault.
 
Last edited:
As I type this, I'm having the high ping issue. I thought it'd be best to wait before posting a BGM graph to actually get and example of the ping issue. Like I said, it's intermittent so this is the first time it's happened since my last post. It's still difficult to see the results on the graph so I'll wait and post them once they're not right on the edge of the graph.

Thanks for your help so far KIA.

[EDIT] This is my 700th post... I shall never forget this truly historic moment.
 
Last edited:
Now for a proper update.


RE: Ping tests.

Whenever I have and issue that I believe is ping related, I'll ping 8.8.8.8 (google's DNS server) as web based ping tests are far from reliable, as I'll demonstrate in the rest of this post.

RE: BQM

Here's what it looks like when I have the ping issue.

b6a9ff0b2299c77a709f581f413e2db8.png


[NOTE] I'd seen similar results one previous graphs but seen as though no one was using the internet at the time, I couldn't say whether what was on the graph correlated with the ping problem. The other graphs can be seen HERE and HERE.

As you can see, it shows a huge spike of packet loss, which I find kind of odd as I was still able to ping 8.8.8.8 from the command console and it said there was 0% packet loss. Take note that the following results are somewhat unusual. Usually the pings are consistently high but as you can see, there is the occasional double digit ping amongst the quadrupal digit results. This is the first time I've had a result like this.

Pinging 8.8.8.8 with 32 bytes of data:
Reply from 8.8.8.8: bytes=32 time=1072ms TTL=46
Reply from 8.8.8.8: bytes=32 time=34ms TTL=46
Reply from 8.8.8.8: bytes=32 time=2940ms TTL=46
Reply from 8.8.8.8: bytes=32 time=2942ms TTL=46
Reply from 8.8.8.8: bytes=32 time=2973ms TTL=46
Reply from 8.8.8.8: bytes=32 time=3077ms TTL=46
Reply from 8.8.8.8: bytes=32 time=3126ms TTL=46
Reply from 8.8.8.8: bytes=32 time=1438ms TTL=46
Reply from 8.8.8.8: bytes=32 time=35ms TTL=46
Reply from 8.8.8.8: bytes=32 time=3184ms TTL=46
Reply from 8.8.8.8: bytes=32 time=3274ms TTL=46
Reply from 8.8.8.8: bytes=32 time=1712ms TTL=46
Reply from 8.8.8.8: bytes=32 time=1609ms TTL=46
Reply from 8.8.8.8: bytes=32 time=1608ms TTL=46
Reply from 8.8.8.8: bytes=32 time=1613ms TTL=46
Reply from 8.8.8.8: bytes=32 time=1659ms TTL=46
Reply from 8.8.8.8: bytes=32 time=1705ms TTL=46
Reply from 8.8.8.8: bytes=32 time=325ms TTL=46
Reply from 8.8.8.8: bytes=32 time=1853ms TTL=46
Reply from 8.8.8.8: bytes=32 time=1806ms TTL=46
Reply from 8.8.8.8: bytes=32 time=1905ms TTL=46
Reply from 8.8.8.8: bytes=32 time=1900ms TTL=46
Reply from 8.8.8.8: bytes=32 time=1996ms TTL=46
Reply from 8.8.8.8: bytes=32 time=1999ms TTL=46
Reply from 8.8.8.8: bytes=32 time=2101ms TTL=46
Reply from 8.8.8.8: bytes=32 time=2093ms TTL=46
Reply from 8.8.8.8: bytes=32 time=1152ms TTL=46
Reply from 8.8.8.8: bytes=32 time=42ms TTL=46
Reply from 8.8.8.8: bytes=32 time=2210ms TTL=46
Reply from 8.8.8.8: bytes=32 time=2241ms TTL=46
Reply from 8.8.8.8: bytes=32 time=2299ms TTL=46
Reply from 8.8.8.8: bytes=32 time=2368ms TTL=46
Reply from 8.8.8.8: bytes=32 time=2448ms TTL=46
Reply from 8.8.8.8: bytes=32 time=2445ms TTL=46
Reply from 8.8.8.8: bytes=32 time=2487ms TTL=46
Reply from 8.8.8.8: bytes=32 time=27ms TTL=46
Reply from 8.8.8.8: bytes=32 time=2552ms TTL=46
Reply from 8.8.8.8: bytes=32 time=2638ms TTL=46
Reply from 8.8.8.8: bytes=32 time=2682ms TTL=46
Reply from 8.8.8.8: bytes=32 time=2679ms TTL=46
Reply from 8.8.8.8: bytes=32 time=2729ms TTL=46
Reply from 8.8.8.8: bytes=32 time=2781ms TTL=46
Reply from 8.8.8.8: bytes=32 time=407ms TTL=46
Reply from 8.8.8.8: bytes=32 time=2809ms TTL=46
Reply from 8.8.8.8: bytes=32 time=2879ms TTL=46

Ping statistics for 8.8.8.8:
Packets: Sent = 45, Received = 45, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 27ms, Maximum = 3274ms, Average = 1996ms

Whilst I was having the ping issue, I also tried running a quick speedtest. The ping isn't exactly consistent with the cmd results or consistent with the time it actually took to get a result. It took well over three seconds for it to report the ping.

2741810008.png


This time, I've left the modem and router alone. Neither of them has been reset since my last post (which is when I started using BQM). Here's the result that I'm getting now.

2741911338.png


64 bytes from 8.8.8.8: icmp_req=1 ttl=46 time=28.2 ms
64 bytes from 8.8.8.8: icmp_req=2 ttl=46 time=27.6 ms
64 bytes from 8.8.8.8: icmp_req=3 ttl=46 time=37.3 ms
64 bytes from 8.8.8.8: icmp_req=4 ttl=46 time=37.7 ms
64 bytes from 8.8.8.8: icmp_req=5 ttl=46 time=42.2 ms
64 bytes from 8.8.8.8: icmp_req=6 ttl=46 time=28.1 ms
64 bytes from 8.8.8.8: icmp_req=7 ttl=46 time=27.2 ms
64 bytes from 8.8.8.8: icmp_req=8 ttl=46 time=37.6 ms
64 bytes from 8.8.8.8: icmp_req=9 ttl=46 time=27.7 ms
64 bytes from 8.8.8.8: icmp_req=10 ttl=46 time=37.9 ms
64 bytes from 8.8.8.8: icmp_req=11 ttl=46 time=30.2 ms
64 bytes from 8.8.8.8: icmp_req=12 ttl=46 time=32.3 ms
64 bytes from 8.8.8.8: icmp_req=13 ttl=46 time=30.9 ms
64 bytes from 8.8.8.8: icmp_req=14 ttl=46 time=30.3 ms
64 bytes from 8.8.8.8: icmp_req=15 ttl=46 time=53.5 ms
64 bytes from 8.8.8.8: icmp_req=16 ttl=46 time=36.8 ms
64 bytes from 8.8.8.8: icmp_req=17 ttl=46 time=26.1 ms
64 bytes from 8.8.8.8: icmp_req=18 ttl=46 time=33.9 ms
64 bytes from 8.8.8.8: icmp_req=19 ttl=46 time=37.7 ms
64 bytes from 8.8.8.8: icmp_req=20 ttl=46 time=37.6 ms
 
Can you show a BQM of what it's like when the superhub is acting as the router without the ASUS connected?
 
I'll give it a go but the last time I used the superhub as a router, the wireless completely stopped working. I tried resetting it numerous times and leaving it unplugged for half and hour but no matter what I tried, I just could not get the wireless to work again.

[EDIT] The BQM is up and running, I'll let you know when I get some meaningful data.
 
Last edited:
Here's some juicy data. I checked my new BQM and these are the results.

78adac96588d7e5bdb8bc0405f1b2ebc-31-05-2013.png


direct link - http://www.thinkbroadband.com/ping/share/78adac96588d7e5bdb8bc0405f1b2ebc-31-05-2013.html

Here are the results of a cmd ping test .

ping -t 8.8.8.8

Pinging 8.8.8.8 with 32 bytes of data:
Request timed out.
Request timed out.
Request timed out.
Request timed out.

Ping statistics for 8.8.8.8:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss)

[EDIT] It appears that the pings timing out are down to the superhub's firewall settings.

Here's a speedtest result (for what it's worth). Again, the amount of time it took to run the ping part of the test and the result were vastly different.

 
Last edited:
At least you've been able to rule out the N66U. There's definitely a fault somewhere. I would post on the VM support forum.
 
I'm jumping ship to Plusnet on the 4th so, now that it the n66u has been ruled out as the cause of the current problem, it's not really a big issue for me. I'll still let VM know there's a problem though, just in case the problem is on their end.

Thanks for the help KIA. I've been looking through various networking related threads in the last few weeks and you always pop up, giving helpful advice. So, keep up the good work. Thanks again.
 
Back
Top Bottom