09-14-2006, 12:52 AM
|
| |
 Re: odd traceroute...
On 12 Sep 2006, in the Usenet newsgroup alt.internet.wireless, in article
<1158128283.054383.115590@d34g2000cwd.googlegroups .com>, KraftDiner wrote:
>I've noticed a long delay whenever i type in a url in to my browser...
>I decided to do a traceroute to see what was wrong..
Probably not the best solution. First, the original LBL traceroute is
using UDP - your web browser uses TCP, and some routers treat the two
protocols differently (UDP is generally lower in priority). The b0rked
windoze "TRACERT" and a few "improved" UNIX traceroute implementations
use ICMP echo (ping) which is even more useless. Second, a more
suitable tool would be a packet sniffer. Are you seeing retransmits?
> 1 192.168.1.1 (192.168.1.1) 3.819 ms 2.097 ms 1.938 ms
> 2 * * *
> 3 rd1no-ge3-0-0-1.cg.shawcable.net (64.59.142.115) 22.471 ms 10.471 ms
> 8.648 ms
man traceroute - the LBL man page is quite extensive. Look at the -q and
-w options
-q nqueries
Set the number of probes per ``ttl'' to nqueries (default is
three probes).
-w Set the time (in seconds) to wait for a response to a probe
(default 5 sec.).
and the examples in the man page.
>Notice the 2nd hop.. RIght between my wireless NAT/Router and my ISP.
>It takes a good ten seconds to get to the third hop.
The second hop is ignoring/blocking/dropping UDP and/or isn't providing an
ICMP Type 11 error for some reason - often, a misguided attempt at some
form of security. Your traceroute has to wait for each attempt to time out
before heading for hop 3. Normal. This has absolutely nothing to do
with delays in loading a web page - notice that hops after this host are
not showing significant delays because hop 2 isn't talkative.
>Does the ISP need to be provided with DNS information or does that all
>get automatically resolved by DHCP?
Nothing to do with it - but you _could_ use the -n option to tell traceroute
not to look up the hostnames. You probably won't see a difference in the
reported delays.
>Or am I barking up the completely wrong tree? If so what else should I
>be looking at?
Not enough information. I'd be looking at tcpdump (or what ever packet
sniffer you have on that box and are comfortable with) to see what the
packets are doing. There are quite a number of possibilities. As for
trying to locate delays enroute, I don't know if tcptraceroute or hping2 is
available for OSX (applications that can run a traceroute using TCP instead
of UDP), but I suspect your problem lies elsewhere. Certainly the two
traces you provide show no network problems.
Old guy
 |
Linear Mode
