Jump to content

brought [most of] the router to a standstill


Recommended Posts

  • Replies 61
  • Created
  • Last Reply

with 1.4mB/s D and 2.6kB/s U loads [my son knew i had started a download while playing battlefield 4.]

 

Microsoft Windows [Version 6.3.9600]
© 2013 Microsoft Corporation. All rights reserved.
 
C:\Users\5cents>ping 8.8.8.8
 
Pinging 8.8.8.8 with 32 bytes of data:
Reply from 8.8.8.8: bytes=32 time=1864ms TTL=55
Reply from 8.8.8.8: bytes=32 time=1136ms TTL=55
Reply from 8.8.8.8: bytes=32 time=1263ms TTL=55
Reply from 8.8.8.8: bytes=32 time=1818ms TTL=55
 
Ping statistics for 8.8.8.8:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 1136ms, Maximum = 1864ms, Average = 1520ms
 
C:\Users\5cents>ping 192.168.0.1
 
Pinging 192.168.0.1 with 32 bytes of data:
Reply from 192.168.0.1: bytes=32 time<1ms TTL=64
Reply from 192.168.0.1: bytes=32 time=1ms TTL=64
Reply from 192.168.0.1: bytes=32 time<1ms TTL=64
Reply from 192.168.0.1: bytes=32 time<1ms TTL=64
 
Ping statistics for 192.168.0.1:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 0ms, Maximum = 1ms, Average = 0ms
 
C:\Users\5cents>ping 192.168.100.1
 
Pinging 192.168.100.1 with 32 bytes of data:
Reply from 192.168.100.1: bytes=32 time=1ms TTL=63
Reply from 192.168.100.1: bytes=32 time<1ms TTL=63
Reply from 192.168.100.1: bytes=32 time=1ms TTL=63
Reply from 192.168.100.1: bytes=32 time<1ms TTL=63
 
Ping statistics for 192.168.100.1:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 0ms, Maximum = 1ms, Average = 0ms
 
C:\Users\5cents>ping 8.8.8.8
 
Pinging 8.8.8.8 with 32 bytes of data:
Reply from 8.8.8.8: bytes=32 time=263ms TTL=55
Reply from 8.8.8.8: bytes=32 time=652ms TTL=55
Reply from 8.8.8.8: bytes=32 time=540ms TTL=55
Reply from 8.8.8.8: bytes=32 time=876ms TTL=55
 
Ping statistics for 8.8.8.8:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 263ms, Maximum = 876ms, Average = 582ms
 
C:\Users\5cents>ping 8.8.8.8
 
Pinging 8.8.8.8 with 32 bytes of data:
Reply from 8.8.8.8: bytes=32 time=1051ms TTL=55
Reply from 8.8.8.8: bytes=32 time=1111ms TTL=55
Reply from 8.8.8.8: bytes=32 time=991ms TTL=55
Reply from 8.8.8.8: bytes=32 time=1029ms TTL=55
 
Ping statistics for 8.8.8.8:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 991ms, Maximum = 1111ms, Average = 1045ms
 
C:\Users\5cents>ping 192.168.0.1
 
Pinging 192.168.0.1 with 32 bytes of data:
Reply from 192.168.0.1: bytes=32 time<1ms TTL=64
Reply from 192.168.0.1: bytes=32 time<1ms TTL=64
Reply from 192.168.0.1: bytes=32 time<1ms TTL=64
Reply from 192.168.0.1: bytes=32 time<1ms TTL=64
 
Ping statistics for 192.168.0.1:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 0ms, Maximum = 0ms, Average = 0ms
 
C:\Users\5cents>ping 192.168.100.1
 
Pinging 192.168.100.1 with 32 bytes of data:
Reply from 192.168.100.1: bytes=32 time=1ms TTL=63
Request timed out.
Reply from 192.168.100.1: bytes=32 time<1ms TTL=63
Reply from 192.168.100.1: bytes=32 time<1ms TTL=63
 
Ping statistics for 192.168.100.1:
    Packets: Sent = 4, Received = 3, Lost = 1 (25% loss),
Approximate round trip times in milli-seconds:
    Minimum = 0ms, Maximum = 1ms, Average = 0ms
 
C:\Users\5cents>ping 192.168.100.1
 
Pinging 192.168.100.1 with 32 bytes of data:
Reply from 192.168.100.1: bytes=32 time<1ms TTL=63
Reply from 192.168.100.1: bytes=32 time<1ms TTL=63
Reply from 192.168.100.1: bytes=32 time<1ms TTL=63
Reply from 192.168.100.1: bytes=32 time<1ms TTL=63
 
Ping statistics for 192.168.100.1:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 0ms, Maximum = 0ms, Average = 0ms
 
C:\Users\5cents>ping 192.168.100.1
 
Pinging 192.168.100.1 with 32 bytes of data:
Request timed out.
Reply from 192.168.100.1: bytes=32 time<1ms TTL=63
Reply from 192.168.100.1: bytes=32 time<1ms TTL=63
Reply from 192.168.100.1: bytes=32 time<1ms TTL=63
 
Ping statistics for 192.168.100.1:
    Packets: Sent = 4, Received = 3, Lost = 1 (25% loss),
Approximate round trip times in milli-seconds:
    Minimum = 0ms, Maximum = 0ms, Average = 0ms
 
C:\Users\5cents>tracert 8.8.8.8
 
Tracing route to google-public-dns-a.google.com [8.8.8.8]
over a maximum of 30 hops:
 
  1    <1 ms     1 ms    <1 ms  R1.lan [192.168.0.1]
  2     *        *        *     Request timed out.
  3  1116 ms  1070 ms  1131 ms  dtr01ahvlnc-tge-0-1-0-3.ahvl.nc.charter.com [96.
34.67.49]
  4  1169 ms  1161 ms  1136 ms  crr01ahvlnc-bue-20.ahvl.nc.charter.com [96.34.93
.250]
  5   871 ms   877 ms  1183 ms  crr11gnvlsc-bue-10.gnvl.sc.charter.com [96.34.93
.243]
  6  1116 ms  1071 ms     *     bbr01gnvlsc-bue-3.gnvl.sc.charter.com [96.34.2.1
12]
  7  1042 ms  1095 ms  1311 ms  bbr01spbgsc-bue-1.spbg.sc.charter.com [96.34.0.4
2]
  8     *      481 ms   839 ms  bbr02atlnga-bue-4.atln.ga.charter.com [96.34.0.4
0]
  9  1068 ms  1148 ms   973 ms  prr01atlnga-bue-3.atln.ga.charter.com [96.34.3.1
9]
 10   991 ms  1003 ms  1205 ms  72.14.220.17
 11  1117 ms  1195 ms  1118 ms  209.85.243.239
 12     *     1105 ms  1269 ms  66.249.95.97
 13   967 ms  1125 ms  1224 ms  google-public-dns-a.google.com [8.8.8.8]
 
Trace complete.

 

 

 

so <1ms to R1, <1ms [and some loss] to modem [192.168.100.1], LOTS of delay to google....

Link to comment
Share on other sites

download hit 2.0mB/s, all other devices lost connection. i had to lower it to 500kB/s to bring other devices back online

 

here is the test from another machine

 

 

Microsoft Windows [Version 6.1.7601]

Copyright © 2009 Microsoft Corporation.  All rights reserved.
 
downloads not running.
C:\>ping 8.8.8.8
 
Pinging 8.8.8.8 with 32 bytes of data:
Reply from 8.8.8.8: bytes=32 time=19ms TTL=55
Reply from 8.8.8.8: bytes=32 time=23ms TTL=55
Reply from 8.8.8.8: bytes=32 time=21ms TTL=55
Reply from 8.8.8.8: bytes=32 time=18ms TTL=55
 
Ping statistics for 8.8.8.8:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 18ms, Maximum = 23ms, Average = 20ms
 
downloads running:
 
C:\>ping 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),
 
C:\>ping 192.168.0.1
 
Pinging 192.168.0.1 with 32 bytes of data:
Reply from 192.168.0.1: bytes=32 time<1ms TTL=64
Reply from 192.168.0.1: bytes=32 time<1ms TTL=64
Reply from 192.168.0.1: bytes=32 time<1ms TTL=64
Reply from 192.168.0.1: bytes=32 time<1ms TTL=64
 
Ping statistics for 192.168.0.1:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 0ms, Maximum = 0ms, Average = 0ms
 
C:\>ping 192.168.100.1
 
Pinging 192.168.100.1 with 32 bytes of data:
Reply from 192.168.100.1: bytes=32 time<1ms TTL=63
Reply from 192.168.100.1: bytes=32 time<1ms TTL=63
Reply from 192.168.100.1: bytes=32 time<1ms TTL=63
Reply from 192.168.100.1: bytes=32 time<1ms TTL=63
 
Ping statistics for 192.168.100.1:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 0ms, Maximum = 0ms, Average = 0ms
 
C:\>
Link to comment
Share on other sites

here is a tracert with the downloads throttled to 500kB/s

 

 

Microsoft Windows [Version 6.1.7601]

Copyright © 2009 Microsoft Corporation.  All rights reserved.
 
C:\>tracert 8.8.8.8
 
Tracing route to google-public-dns-a.google.com [8.8.8.8]
over a maximum of 30 hops:
 
  1    <1 ms    <1 ms    <1 ms  R1.lan [192.168.0.1]
  2     *        *        *     Request timed out.
  3   270 ms   255 ms   230 ms  dtr01ahvlnc-tge-0-1-0-3.ahvl.nc.charter.com [96.
34.67.49]
  4    87 ms    51 ms    44 ms  crr01ahvlnc-bue-20.ahvl.nc.charter.com [96.34.93
.250]
  5   325 ms   377 ms   298 ms  crr11gnvlsc-bue-10.gnvl.sc.charter.com [96.34.93
.243]
  6    57 ms    68 ms    92 ms  bbr01gnvlsc-bue-3.gnvl.sc.charter.com [96.34.2.1
12]
  7    56 ms    31 ms    31 ms  bbr01spbgsc-bue-1.spbg.sc.charter.com [96.34.0.4
2]
  8    58 ms    39 ms    23 ms  bbr02atlnga-bue-4.atln.ga.charter.com [96.34.0.4
0]
  9    53 ms    58 ms    64 ms  prr01atlnga-bue-3.atln.ga.charter.com [96.34.3.1
9]
 10   123 ms   165 ms   179 ms  72.14.220.17
 11    17 ms    37 ms    25 ms  209.85.243.239
 12    72 ms    82 ms    76 ms  66.249.95.97
 13    27 ms    18 ms    31 ms  google-public-dns-a.google.com [8.8.8.8]
 
Trace complete.
 
C:\>
Link to comment
Share on other sites

from router diagnostics

 

 

Ping

PING 8.8.8.8 (8.8.8.8): 56 data bytes
64 bytes from 8.8.8.8: seq=0 ttl=56 time=17.013 ms
64 bytes from 8.8.8.8: seq=1 ttl=56 time=18.283 ms
64 bytes from 8.8.8.8: seq=2 ttl=56 time=16.573 ms
64 bytes from 8.8.8.8: seq=3 ttl=56 time=17.598 ms
64 bytes from 8.8.8.8: seq=4 ttl=56 time=15.918 ms
64 bytes from 8.8.8.8: seq=5 ttl=56 time=17.706 ms
64 bytes from 8.8.8.8: seq=6 ttl=56 time=18.532 ms
64 bytes from 8.8.8.8: seq=7 ttl=56 time=17.247 ms
64 bytes from 8.8.8.8: seq=8 ttl=56 time=18.122 ms
64 bytes from 8.8.8.8: seq=9 ttl=56 time=16.251 ms
64 bytes from 8.8.8.8: seq=10 ttl=56 time=23.962 ms
64 bytes from 8.8.8.8: seq=11 ttl=56 time=17.135 ms
64 bytes from 8.8.8.8: seq=12 ttl=56 time=17.476 ms
64 bytes from 8.8.8.8: seq=13 ttl=56 time=18.566 ms
64 bytes from 8.8.8.8: seq=14 ttl=56 time=19.953 ms
64 bytes from 8.8.8.8: seq=15 ttl=56 time=18.448 ms
64 bytes from 8.8.8.8: seq=16 ttl=56 time=16.208 ms
64 bytes from 8.8.8.8: seq=17 ttl=56 time=17.487 ms
64 bytes from 8.8.8.8: seq=18 ttl=56 time=16.887 ms
64 bytes from 8.8.8.8: seq=19 ttl=56 time=16.987 ms
 
--- 8.8.8.8 ping statistics ---
20 packets transmitted, 20 packets received, 0% packet loss
round-trip min/avg/max = 15.918/17.817/23.962 ms
Trace
traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 38 byte packets
1 * * *
2 96.34.67.49 8.700 ms 9.052 ms 11.936 ms
3 96.34.93.250 9.592 ms 15.953 ms 9.617 ms
4 96.34.93.243 11.601 ms 13.071 ms 25.093 ms
5 96.34.2.112 31.454 ms 15.598 ms 15.772 ms
6 96.34.0.42 18.224 ms 15.828 ms 15.882 ms
7 96.34.0.40 20.662 ms 23.483 ms 23.592 ms
8 96.34.3.19 16.937 ms 17.039 ms 24.581 ms
9 72.14.220.17 17.494 ms 17.094 ms 18.311 ms
10 209.85.243.239 18.480 ms 72.14.235.193 19.134 ms 209.85.240.239 15.578 ms
11 66.249.94.151 20.401 ms 66.249.95.101 33.747 ms 18.479 ms
12 8.8.8.8 16.732 ms 18.166 ms 15.519 ms
Link to comment
Share on other sites

Silly question time but you sure your ISP isn't throttling you once torrents kick in? I've seen it happen before so only a guess as it's not the router going to a standstill it's your connection being saturated it looks like.

Link to comment
Share on other sites

  • Administrators

this sounds very much like the dodgy modem bug. Can you message a member from Cox called odog here. Out of the kindess of his own heart he investigated a similar problem and found that the modem had a bug. 

Link to comment
Share on other sites

What do you see when you just use your isp modem/router on its own, no duma inline and test using torrents?

 

i only have standalone modem, my other routers [cisco and netgear] work fine even when running 4mB/s on the torrents. i cant imagine that my ISP throttles as they say they dont.

 

as of right now, i have to throttle my utorrent client to 500kB/s for internet to stay up. i have never had to do that before. so i know its not the modem itself. its something between the modem and the R1.

Link to comment
Share on other sites

the only other thing i can think of which i dont really want to do is put the R1 onto another router that i have and connect my media center to that router and the rest onto the R1. but honestly, the R1 should just work without the need to cascade.

Link to comment
Share on other sites

Silly question time but you sure your ISP isn't throttling you once torrents kick in? I've seen it happen before so only a guess as it's not the router going to a standstill it's your connection being saturated it looks like.

 

25% of my network load shouldnt saturate the connection... and at that point my congestion controls should kick in.

Link to comment
Share on other sites

  • Administrators

Hi pro, 

 

believe me the bug is confusing & very annoying but its 100% a bug with the modem odog confirmed it. He hasn't explained to me exactly what the bug so I can't explain it either. I assume he's under an NDA with Motorola/Cisco. But please try contact him and he will hopefully push out upgrade to you. 

Link to comment
Share on other sites

Unfortunately if the 2 other routers I own work perfectly fine, also the issue in the other thread isn't my problem... I can run 4+ HD streams as the same time with no slowdown.

 

Something else is at play here. If I can use my Cisco and netgear in same setup and I don't experience the slowdown it seems it would be the R1 and not my modem. Also it is not the same model in the other thread, however the modem I use is probably one of the most used cable modems in US.

 

Is there any other troubleshooting I can do? I have "special tools" I can monitor my network with but would need to know what to look for if anyone can help.

Link to comment
Share on other sites

  • Administrators

Hi Procreate, 

 

Firstly its hard to communicate tone, I'm not being defensive here I've just addressed this annoying problem before. Having said that I'll continue, I fully understand your logic because I found it very confusing myself, but here are the key points ( number 1 being the most important ):

  • The ping rises at the modem no where else
  • The netduma works on many many modems worldwide
  • Internet network nodes are meant to be compliant with each other to the standards specified in RFCs

 

For some reason those modems have a bug in them that odog found that makes the ping go erratic & the throughput drop. Did you try contact odog? He will send you the fix. Believe me I understand where you're coming from but the facts of the matter is we've already identified this issue and found the problem, the aforementioned bug in the firmware of those modems. 

 

I'm going to get Alex & Scott two other people with this issue to reply here as well. 

Link to comment
Share on other sites

Hello Pro

 

My ISP is Cox and back in December I upgraded my Astros/ Motorola SB6141 to the SB6183. I thought this would be best for the service I am paying for Ultimate.

 

About the end of Feb while watching Netflix it began to buffer mid movie. I rebooted everything: Modem, Netgear Router, R1 and Xbox One. Everything back to normal. But a month later it started happening more frequently and not even rebooting helped at times.

 

Per Iain and Odog it is a bug in the Motorola modem so Odog sent me a different modem from Netgear to use until they can patch the bug. So thanks to Odog, Scott and Iain for helping me out.

 

I haven't encountered that problem since I started using the Netgear Modem so it definitely is the Motorola. A Youtuber named Capp00 who is in networking said earlier this year that he dislikes Arris because their product always has problems.

 

Hope this helps. Hope to hear from Odog too and see what he has been able to do or find out. He doesn't frequent the site much but his help and everyone else has been God sent!

Link to comment
Share on other sites

You aren't coming across as defensive. Hope I am coming across as confused. Works fine on router A and B but not C... See my logic?

 

I will try and get in touch with odog but I believe only ISP can push firmware to modems... At least I don't see anywhere in its panel to do so.

 

I just want to figure this out so I don't have to cascade my setup.

Link to comment
Share on other sites

Well guy's this problem from what I can see affects a couple different Motorola modem model's. As they use the same kind of chipset, some can bond more channel's, and such. However it's still the same brand of chipset being used within the modem's themselves. This issue is very tricky, and it's hard to get a hold of, and understanding of. But from the data I collected myself, the netduma router may send its data in a bit of a different pattern compared to other routers. However the modem itself should be able to handle it without issue. I'm not 100% on this, but I think the netduma router manages to cause a memory leak within the modem.

 

So once that memory leak is exposed within the modem, guess what? Pings go to crap, as does your connection. Only way to resolve the issue, is to reboot your modem every time it happens. I troubleshooted this issue for over a month straight myself. I would disconnect the R1 once this issue started, direct connection to the modem, and the issue would continue to happen until a reboot of the modem was done. So the R1 does indeed cause the modem to go into this problematic state, however that doesn't mean the router itself is to blame.

 

In this case, there is a bug within the firmware for some of these modems. I was able to send odog my R1 to troubleshoot with the same modem i'm currently using which is a Motorola SB6183. He was able to get the issue to occur, and sent the proper data back to Motorola to correct this problem in a future firmware build. The thing is, there is no real time table for a new firmware from Motorola. It could still be several months from this point in time. Then once they give the firmware over to the ISP's, it could be another month, or so of internal testing before they feel safe releasing it to there customers.

 

Also odog only works for Cox, and if you're with another ISP with this same issue. You will have to take this up with them on getting it resolved. There is a little work around to this, and that would be connecting the R1 into your previous router, and only run your gaming consoles threw the R1, and keep them machines from using steady amounts of large data. The other option is buy another modem, that doesn't use this chipset as a lot of the motorola use the same one. I think odog sent me a Motorola SB6141, and I owned 3 other motorola modems. However only the SB6141 used a different chipset. All three of mine, used the same one, and all had this issue.

Link to comment
Share on other sites

  • Administrators

Sure believe me I'm very confused I wish odog would(or more likely could as its probably legal) tell me exactly what the bug is. As I agree with you the Netduma must obviously be doing something if the other routers don't do it BUT I think the modem handles the traffic incorrectly so its actually a bug with the modem that the Netduma makes visible. 

 

Hopefully Scott will come in here as he knows odog personally and introduces me to him personally. 

Link to comment
Share on other sites

Well at least I am not having as bad a problem as the other thread. Mine is manageable, just not optimal. I wonder if it's the ddwrt platform it's built upon? I will do some more checking now that I am back home.

 

My current firmware is SB_KOMODO-1.0.6.6-SCM00-NOSH now that I am able to access my network if that is of any use.

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.


×
×
  • Create New...