|reply to TexasRebel |
Re: Gen4/Changes Coming After Jan 1
said by TexasRebel:No. It COULD meant that, but rarely does on a ping or tracert.
Everywhere you see timeouts, means it's dropping packets because the bandwidth isn't there or it a software problem..
What it USUALLY means is a router that is setup to not respond to ICMP requests. Not at all uncommon on some networks.
If the final IP in a tracert does not accept ICMP, then the trace never completes. for intermediates, you just get a timeout and it moves on.
An example of a site that won't accept? Try tracing or pinging www.microsoft.com
Motosat self-pointing dishes: .74 meter G74 on 127W, SL-5 HD DirecTV|Hughes HN7000S|Verizon UMW190 Air Card|1990 Blue Bird Wanderlodge Bus "Blue Thunder"|Author of hnFAP-Alert, PC-OPI and DSSatTool
no, it's definitely a bandwidth issue or a software issue on the ground. here's a tracert I did earlier this morning around 6:30am.
I understand about some routers not responding to iCMP pings. But these packet losses are happening during peak times, which it seems for HNG4 it's 9AM-2AM, a 16 hour window.
much different outcome at around 6:30AM.
Tracing route to google-public-dns-a.google.com [220.127.116.11]
over a maximum of 30 hops:
1 1 ms 1 ms 1 ms DD-WRT [192.168.1.251]
2 1 ms 1 ms 1 ms 100.75.0.201
3 650 ms 1539 ms 689 ms dpc6935160130.direcpc.com [18.104.22.168]
4 613 ms 649 ms 618 ms dpc6935164017.direcpc.com [22.214.171.124]
5 661 ms 649 ms 649 ms tuk-edge-11.inet.qwest.net [126.96.36.199]
6 1094 ms 770 ms 748 ms sea-edge-12.inet.qwest.net [188.8.131.52]
7 622 ms 679 ms 649 ms 184.108.40.206
8 701 ms 661 ms 659 ms 220.127.116.11
9 1696 ms 859 ms 639 ms 18.104.22.168
10 1288 ms 629 ms 689 ms 22.214.171.124
11 619 ms 644 ms 654 ms 126.96.36.199
12 * * * Request timed out.
13 655 ms 659 ms 639 ms google-public-dns-a.google.com [188.8.131.52]
OK, since the missing hops are mostly outside the Hughes network it probably just is a true timeout. Have your tried opening up the tracert timeout window?