|
[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]
|
Re: [tcptra-dev] tcptraceroute-1.5beta1
|
Michael,
I borrowed a RedHat 7.1 system, finally got it working adequately, so
I have some output to offer you. I regret I may be giving you stuff
that we've already discussed as not productive toward analysis. I'm
finding there is no difference between the output of tcptraceroute 1.4-1
on RedHat and 1.5-beta2. Here it is:
[root] /tmp >> tcptraceroute 127.0.0.1 # localhost
Selected device lo, address 127.0.0.1, port 1087 for outgoing packets
Tracing the path to 127.0.0.1 on TCP port 80, 30 hops max
1 localhost (127.0.0.1) [closed] 0.256 ms 0.160 ms 0.150 ms
[root] /tmp >> tcptraceroute mogwai # firewall/router
Selected device eth0, address 192.168.1.200, port 1088 for outgoing packets
Tracing the path to mogwai (24.163.210.43) on TCP port 80, 30 hops max
1 mogwai (24.163.210.43) [closed] 1.176 ms 0.926 ms 0.913 ms
[root] /tmp >> tcptraceroute 24.26.162.4 # first hop after router
Selected device eth0, address 192.168.1.200, port 1089 for outgoing packets
Tracing the path to 24.26.162.4 on TCP port 80, 30 hops max
1 24.26.162.4 (24.26.162.4) [closed] 62.989 ms 27.892 ms 25.807 ms
[root] /tmp >> tcptraceroute 66.185.141.202 # second hop after router, probably doesn't work due to asymmetric routing
Selected device eth0, address 192.168.1.200, port 1090 for outgoing packets
Tracing the path to 66.185.141.202 on TCP port 80, 30 hops max
1 * * *
2 * * *
3 * * *
4 * * *
5 * * *
6 * * *
7 * * *
8 * * *
9 * * *
10 * * *
11 * * *
12 * * *
13 * * *
14 * * *
15 * * *
16 * * *
17 * * *
18 * * *
19 * * *
20 * * *
21 * * *
22 * * *
23 * * *
24 * * *
25 * * *
26 * * *
27 * * *
28 * * *
29 * * *
30 * * *
Destination not reached
[root] /tmp >> tcptraceroute 207.8.132.197 # toren.net (same as before)
Selected device eth0, address 192.168.1.200, port 1091 for outgoing packets
Tracing the path to 207.8.132.197 on TCP port 80, 30 hops max
1 * * *
2 * * *
3 * * *
4 * * *
5 * * *
6 * * *
7 * * *
8 * * *
9 * * *
10 * * *
11 * * *
12 207.8.132.197 (207.8.132.197) [open] 66.702 ms 78.870 ms 66.992 ms
[root] /tmp >>
I haven't tried power-cycling the router as of yet.
If there's anything you'd like me to try from RedHat please let me know
sooner than later.
--Joel
> > Just to be sure you have this straight... The model of LinkSys
> > router/firewall is BEFSX41.
>
> Yup, I remember, thanks. Unfortunately, I can't give you any specific
> advice in regard to this Linksys product, as I don't have any first hand
> experience with it.
>
> > Here's the output you want to see:
> >
> > # ./tcptraceroute toren.net
> > Selected device en0, address 192.168.1.200, port 49223 for outgoing packets
> > Tracing the path to toren.net (207.8.132.197) on TCP port 80 (http), 30 hops max
> > 1 * * *
> [..]
> > 12 www.toren.net (207.8.132.197) [open] 59.648 ms 60.121 ms 62.632 ms
>
> > I have the output for tcptraceroute -d 66.135.192.87 below. I did, however,
> > run the output through uniq to delete repeated cases of "debug: null pointer
> > from pcap-next()". Here's the output:
>
> That's very interesting. Based upon output of "tcptraceroute toren.net",
> "tcptraceroute -d 66.135.192.87", and upon the fact that a traditional
> traceroute is also not working for you, I would have to say that it appears
> as if your Linksys is blocking inbound ICMP time-exceeded messages, which
> are required for tcptraceroute to determine the IP address of each hop
> along the path to the destination.
>
> Would it be possible to reboot the Linksys device, as Charles suggested, or
> perhaps temporarily remove it from your network configuration and giving
> your MacOS X machine direct access to the internet? Alternatively, as we
> know that tcptraceroute functions properly on your RedHat machine at work,
> it would be interesting to know weather or not tcptraceroute functions
> properly on a RedHat machine at home, going through the Linksys device as
> your MacOS X machine currently does.
>
> > Also, recall the traceroute I did from work to my home system:
>
> Thanks. Unfortunately, due to the way in which traceroute operates, this
> doesn't provide us with many useful clues as to why outbound traceroutes
> from your home machine aren't working. tracerouting in one direction is
> largely independent from tracerouting in the other direction.
>
> -mct
> _______________________________________________
> tcptraceroute-dev mailing list
> tcptraceroute-dev@netisland.net
> https://lists.netisland.net/mailman/listinfo/tcptraceroute-dev
>
_______________________________________________
tcptraceroute-dev mailing list
tcptraceroute-dev@netisland.net
https://lists.netisland.net/mailman/listinfo/tcptraceroute-dev
|
|