Weirdest thing - need a graphical TRACEROUTE freeware for Linux (Centos)

[Zen]

1. Any ideas for a good graphical traceroute freeware for linux?
2. Does it allow routing AROUND certain IP addresses?

WHY:
I've got the weirdest thing going on where I need graphical traceroute
freeware in order to debug a consistent connection problem.

Periodically, one or two IP addresses just go dark for me in that I
can't get to them via the web - or via ping for that matter - but then -
they come back to me weeks or months later.

I know, it's weird.

Meanwhile, I can only get to them by using proxies (such as torbrowser
freeware), or using my laptop on a different network (as all laptops on
my network exhibit the same phenomenon).

I ask my neighbors (on the same ISP as I am), and they have no problem
getting to that network. Huh? It makes no real sense.

Now I know that's weird - but they all seem to stop deep in the
traceroute hierarchy and always on the same routing IP address)
so it would be helpful to screenshot a bunch of graphical traceroutes
to figure out what exactly is happening.

Even better if I could router AROUND this problematic IP address in
the middle!

Here is an example:

$ traceroute www.centos.org
traceroute to www.centos.org (72.232.194.162), 30 hops max, 60 byte packets
1 192.168.1.1 (192.168.1.1) 19.716 ms 19.706 ms 19.696 ms
2 radio (67.218.118.85) 19.688 ms 19.681 ms 19.672 ms
3 10.50.0.1 (10.50.0.1) 69.498 ms 69.504 ms 69.493 ms
4 10.25.0.1 (10.25.0.1) 93.576 ms 93.583 ms 97.166 ms
5 10.20.0.1 (10.20.0.1) 107.068 ms 107.076 ms 109.497 ms
6 10.0.0.1 (10.0.0.1) 116.150 ms 94.368 ms 96.723 ms
7 THE ISP ISP ADDRESS 94.260 ms 96.611 ms 96.606 ms
8 ANOTHER ISP ADDRESS 96.596 ms 55.492 ms 55.469 ms
9 MORE OF THOSE ISP IP ADDRESSES 55.452 ms 55.439 ms 57.901 ms
10 energy-group-networks-llc.10gigabitethernet1-3.core1.sjc1.he.net (64.71.150.22) 71.858 ms 71.857 ms 109.606 ms
11 * * *
12 * * *
13 * * *
14 * * *
15 * * *
16 * * *
17 * * *
18 * * *
19 * * *
20 * * *
21 * * *
22 * * *
23 * * *
24 * * *
25 * * *
26 * * *
27 * * *
28 * * *
29 * * *
30 * * *
$

[Mike Easter]

Zen wrote:
> 1. Any ideas for a good graphical traceroute freeware for linux?

Yes, but...

> 2. Does it allow routing AROUND certain IP addresses?

Of course not.

> WHY:
> I've got the weirdest thing going on where I need graphical traceroute
> freeware in order to debug a consistent connection problem.

I would evaluate that problem by choosing alternate (but) 'non-visual'
traceroute tools.

Default linux traceroute is UDP. Default Win tracert is ICMP. I would
be most interested in tcptraceroute and secondarily in ICMP tracert.
You can find non-visual linux tools for that, and maybe even visual
ones. The visual aspect is 'nice' but it doesn't help you solve the problem.

The problem you have illustrated here is that the UDP packets
don't/can't get from your ISP/ connectivity provider/ to the target centos.

The ICMP and TCP tools would show you what happens to /those/ type
packets. I'm sure the reason you are doing this is because you want to
access the centos site with such as your browser or FTP or something
which uses TCP packets.

> Periodically, one or two IP addresses just go dark for me in that I
> can't get to them via the web - or via ping for that matter - but then -
> they come back to me weeks or months later.

I agree with your workaround strategy to use a proxy.



--
Mike Easter

[Mike Easter]

Mike Easter wrote:

> The problem you have illustrated here is that the UDP packets
> don't/can't get from your ISP/ connectivity provider/ to the target
> centos.

The/My synaptic description for tcptraceroute says:

traceroute implementation using TCP packets

The more traditional traceroute(8) sends out either UDP or ICMP ECHO
packets with a TTL of one, and increments the TTL until the destination
has been reached. By printing the gateways that generate ICMP time
exceeded messages along the way, it is able to determine the path
packets are taking to reach the destination.

The problem is that with the widespread use of firewalls on the modern
Internet, many of the packets that traceroute(8) sends out end up being
filtered, making it impossible to completely trace the path to the
destination. However, in many cases, these firewalls will permit inbound
TCP packets to specific ports that hosts sitting behind the firewall are
listening for connections on. By sending out TCP SYN packets instead of
UDP or ICMP ECHO packets, tcptraceroute is able to bypass the most
common firewall filters.


My default 'Network Tools' which performs a traceroute is not the same
thing as the traceroute which is available in the repos and which can do
UDP or ICMP optionally and of course the default tool cannot do TCP either.

For this work/investigation I would install both of them so that you can
get ICMP and TCP.


--
Mike Easter

[wasbit]

"Zen" <z...@is.invalid> wrote in message news:kemobu$56h$1...@solani.org...

Using the free Etoolz from
- http://www.gaijin.at/en/dlet.php

Host Information for "72.232.194.162":
IP address: 72.232.194.162
Host name: www.centos.org

Tracing route to "72.232.194.162" over max. 30 hops:

1: 11 ms 192.168.0.1
2: 11 ms 80.47.116.1
3: 10 ms 78.151.225.221
4: 13 ms 78.151.225.200
5: 23 ms 62.24.240.13
6: 23 ms 78.144.1.61
7: 24 ms 212.187.192.113
8: 124 ms 4.69.141.189
9: * Request timed out.
9: * Request timed out.
9: * Request timed out.
10: * Request timed out.
10: * Request timed out.
10: * Request timed out.
11: 122 ms 4.69.134.74
12: 122 ms 4.69.148.41
13: 121 ms 4.69.137.121
14: 122 ms 4.69.151.153
15: 128 ms 4.69.145.139
16: 123 ms 4.71.170.2
17: * Request timed out.
17: * Request timed out.
17: * Request timed out.
18: * Request timed out.
18: * Request timed out.
18: * Request timed out.
19: 127 ms 72.232.194.162

The target host "72.232.194.162" have been reached.

Regards
wasbit

[Mike Easter]

Mike Easter wrote:

> Zen wrote:

>> I've got the weirdest thing going on where I need graphical traceroute
>> freeware in order to debug a consistent connection problem.
>
> I would evaluate that problem by choosing alternate (but) 'non-visual'
> traceroute tools.

The DNSStuff online traceroute doesn't solve the question of what is
going on from your own location, but it does give insight into the problem.

If you put www.centos.org into its target field, it provides you an
output of all 3 UDP, ICMP, & TCP plus a graphical display.

The UDP shows absolutely nothing; that is, it goes nowhere. The ICMP
shows all but the last hop to centos; that is, centos doesn't echo the
ICMP ping.

The TCP shows all of the hops, and it also shows an extremely long
latency > 5 sec for the last hop. Apparently centos gives a low
priority to echoing anything, including TCP packets. That is centos
echoes no UDP nor ICMP and it is pokey to handle the TCP.


Beware the wrap below. The columns are:

Hop# ICMPtime UDPtime TCPtime IP Name Country Time

Traceroute Results for www.centos.org [72.232.194.162]

1 1.93 * 2.25 74.115.12.2 NA US Unix: 09:49:26
2 1.21 * 1.12 207.207.44.81 207-207-44-81.fwd.datafoundry.com. US
Unix: 09:49:26
3 1.27 * 1.23 209.99.121.2 g4-0.gw2.aus.datafoundry.net. US
unknown: 09:49:32
4 1.60 * 1.44 209.99.122.65 209-99-122-65.fwd.datafoundry.com. US
Unix: 09:49:32
5 1.04 * 0.99 209.99.14.105 209-99-14-105.fwd.datafoundry.com. US
Unix: 09:49:32
6 2.19 * 1.99 209.66.92.121 xe-0-0-3.mpr1.aus3.us.above.net. US
Linux: 09:49:32
7 1.51 * 1.56 64.125.24.62 xe-1-1-0.mpr1.aus1.us.above.net. US
Linux: 09:49:32
8 6.76 * 6.73 64.125.27.198 xe-2-2-0.cr1.dfw2.us.above.net. US
Linux: 09:49:32
9 6.71 * 6.69 64.125.27.74 xe-0-1-0.er1.dfw2.us.above.net. US
Linux: 09:49:32
10 7.07 * 6.82 4.68.63.37 xe-8-3-0.edge2.dallas3.level3.net. US
Linux: 09:49:32
11 7.31 * 14.62 4.69.145.203 ae-4-90.edge2.Dallas1.Level3.net. US
Linux: 09:49:33
12 7.29 * 7.10 4.71.170.2 LAYERED-TEC.edge2.Dallas1.Level3.net. US
Unix: 09:49:33
13 * * 5027.69 72.232.194.162 www.centos.org. US unknown: 09:49:45


--
Mike Easter

[Zen]

Mike Easter wrote:

Hi Mike,
I'm not sure WHERE to get your tools for Centos?

I did try this graphical traceroute, which shows what I'm seeing:
http://traceroute.monitis.com

Notice that the trace just dies at the 8th hop shown:
http://www4.picturepush.com/photo/a/12116427/img/12116427.png

It died on:
energy-group-networks-llc.10gigabitethernet1-3.core1.sjc1.he.net

I see the same thing with traceroute on Linux (same server!).
...
10 paix.he.net (198.32.176.20) 128.180 ms 120.910 ms 128.149 ms
11 10gigabitethernet3-4.core1.sjc1.he.net (72.52.92.114) 123.322 ms 123.326 ms 132.744 ms
12 energy-group-networks-llc.10gigabitethernet1-3.core1.sjc1.he.net (64.71.150.22) 119.134 ms 119.133 ms 119.606 ms

13 * * *
14 * * *
15 * * *
16 * * *
17 * * *
18 * * *
19 * * *
20 * * *
21 * * *

...

[Joe Mastroianni]

On Mon, 04 Feb 2013 14:55:59 +0000, wasbit wrote:

> Using the free Etoolz from
> - http://www.gaijin.at/en/dlet.php

Try these:
http://traceroute.monitis.com/ (graphical traceroute)
http://www.t1shopper.com/tools/traceroute/ (text traceroute)
http://www.tracert.org/traceroute/ (text traceroute)
http://network-tools.com/ (text traceroute)
http://centralops.net/co/ (also a DNS lookup engine)

[Zen]

Trying another web page, the same problem occurs at the very same server!
http://www.tracert.org/traceroute/

Here is the result:
http://www4.picturepush.com/photo/a/12116547/img/12116547.png

[Aragorn]

On Monday 04 February 2013 21:38, Zen conveyed the following to
alt.os.linux...

There used to be such a thing as xtraceroute. It was a GTK+ front-end
to /usr/sbin/traceroute and it would show a graphical traceroute on a
movable and partly zoomable globe. In the event of a satellite
connection, the line would jump into space, even. ;-)

It's been a while since I've seen it around. Either it was not in the
repositories for the distribution I'm using - I'm running Mageia 1 on
this machine - or else I wasn't looking closely enough.

Mind you that xtraceroute is not Freeware; it is Free Software, and
there is a huge difference between those two concepts. Freeware is
proprietary software of which the use is granted to everyone, and which
as such is downloadable from the internet free of charge.

Free Software is software of which the licensing is Free and the code is
not proprietary, so that you may use, install, study, redistribute,
modify and redistribute your modifications, and to that end, the source
code of the software is made available to everyone. Another name for
Free Software is Open Source Software, although the Free Software
Foundation and the Open Source Initiative have different objectives -
FSF's goals are political, while OSI's goals are pragmatic and
technical. In practice, it boils down to the same thing, however.

--
= Aragorn =
(registered GNU/Linux user #223157)

[cipher]

On Mon, 04 Feb 2013 20:38:47 +0000, Zen Inscribed upon the Golden Tablets
of Usenet thusly:

Works fine here.



--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
)\ ( ) /( Cipher/Proud Member, Netscum Alumni Association
)-(0^^0)-( Bungmunch U./AHM Memorial Institute of F@x0r1n6/Dean
)/ \\// \( Colonel/1st Virginia Volunteers/CeSium Brigade
(oo) Registered Linux User #556617
/ ~~ \ Empire of APDD/#6-5p07/VLNOC Cohort #1407
o@o o@o Keeper of the alt.CeSium FAQ
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

[Mike Easter]

It is somewhat of a waste of time for you to be tracing the route from
someplace else which is not you to centos.org except to demonstrate to
yourself what we have already shown with the one dnsstuff triple
function traceroute from someplace else using UDP, ICMP, and TCP, which
is that centos is only going to echo a TCP packet.

I installed tcptraceroute from the Ub repos and it reached centos with 2
unidentified hops between/within level3 routing and centos.

I'm in SoCal and my connectivity is RR, so my traceroute fundamental is
RR > level3 > centos and centos IP address is in the level3 structure.

It looks to me like the entire level3 part of the route is not going to
echo UDP packets.

That is, lots of networks and their hops won't echo UDP but they echo
ICMP. level3 doesn't echo UDP, but it echoes ICMP (and TCP). centos
webserver is provided by level3 and it chooses to not ICMP (either) and
it only echoes TCP.

So, my TCP traceroute shows all but 2 of the level3 hops and it shows
centos. Your problem with not reaching centos with TCP such as your
browser is not going to be aided by your using tools other than
tcptracertoute because the level3 network doesn't echo UDP and also
because centos only echoes TCP not ICMP or UDP.

5 agg22.lsancarc-ccr01.socal.rr.com (72.129.1.0) 15.354 ms 18.931
ms 15.888 ms
6 ae-6-0.cr0.lax00.tbone.rr.com (66.109.6.212) 19.600 ms 20.796 ms
16.092 ms
7 107.14.19.138 12.448 ms 12.346 ms 13.822 ms
8 66.109.9.122 13.931 ms 12.441 ms 14.018 ms
9 vlan70.csw2.LosAngeles1.Level3.net (4.69.144.126) 53.731 ms
48.745 ms 45.793 ms
10 ae-72-72.ebr2.LosAngeles1.Level3.net (4.69.137.21) 45.779 ms
46.709 ms 46.944 ms
11 ae-3-3.ebr3.Dallas1.Level3.net (4.69.132.78) 47.249 ms 46.780 ms
45.761 ms
12 ae-63-63.csw1.Dallas1.Level3.net (4.69.151.133) 47.814 ms 57.341
ms 46.591 ms
13 ae-1-60.edge2.Dallas1.Level3.net (4.69.145.11) 45.750 ms 48.561
ms 49.804 ms
14 LAYERED-TEC.edge2.Dallas1.Level3.net (4.71.170.2) 47.772 ms
51.352 ms 48.364 ms

15 * * *
16 * * *

17 www.centos.org (72.232.194.162) [open] 45.658 ms 46.598 ms
57.391 ms

The part of the route that is the same for me as for the dnsstuff triple
traceroute is the level3 part to centos, so I understand the
fundamentals of everything between me and centos, but isn't necessarily
the same for you, because you are apparently on a Hurricane Electric
provider structure.

If your centos repos doesn't have tcptraceroute, the website for the one
I used says that it has RedHat rpms
http://michael.toren.net/code/tcptraceroute/

It seems to me if there are redhat rpms, that it would be in the centos
repos.

--
Mike Easter

[Mike Easter]

Mike Easter wrote:

> If your centos repos doesn't have tcptraceroute, the website for the one
> I used says that it has RedHat rpms
> http://michael.toren.net/code/tcptraceroute/
>
> It seems to me if there are redhat rpms, that it would be in the centos
> repos.

Here's a better way to get a repo version of tcptraceroute for CentOS.

Use RPMForge or Repoforge described in the CentOS wiki:

http://wiki.centos.org/AdditionalResources/Repositories/RPMForge
RPMforge is a collaboration of Dag and other packagers. They provide
over 5000 packages for CentOS,

I didn't look in rpmforge, but I looked in the repoforge index
http://pkgs.repoforge.org/ and it has tcptraceroute. So you would
enable the repo in your package manager and then tcptraceroute would be
listed and you would install it from your package manager.


--
Mike Easter

[Mike Easter]

Mike Easter wrote:

> Here's a better way to get a repo version of tcptraceroute for CentOS.
>
> Use RPMForge or Repoforge described in the CentOS wiki:

And once you have repoforge repo and tcptraceroute, you can follow the
instructions in this blog to run a tcpping script.

http://xmodulo.com/2013/01/how-to-install-tcpping-on-linux.html To
install tcptraceroute on CentOS/REHL, first set up RepoForge on your
system, -- download tcpping from the web. -- To measure network latency
by using tcpping, simply run it as follows.


... because the conditions described in the blog prevail for centos, you
can't ping them with ICMP, you can't traceroute them with your UDP
traceroute (or the UDP or even ICMP traceroutes of online tools because
centos doesn't echo anything but TCP)

And, if you can/ when you/ tcpping centos, you really don't care about
the routing, visual or otherwise, because you are just trying to
determine what 'kind of' (latency) connectivity you have to the site.

Incidentally, I can also see centos answer me using IDServe under WINE
on my Mint.

Initiating server query ...
Looking up IP address for domain: www.centos.org
The IP address for the domain is: 72.232.194.162
Connecting to the server on standard HTTP port: 80
[Connected] Requesting the server's default page.
The server returned the following response headers:
<snip http headers>
Query complete.

For me, that IDServe reply is very quick; no hesitancy like the 5 second
latency we saw on the DNSStuff triple traceroute.

--
Mike Easter

[Mike Easter]

Zen wrote:

> Periodically, one or two IP addresses just go dark for me in that I
> can't get to them via the web - or via ping for that matter - but then -
> they come back to me weeks or months later.

I would first use IDServe under Wine. That will quickly show if your
nameservice is resolving the name to the IP and then it will show if the
IP is answering on such as port 80 if it is a browser issue.

You can also use IDServe by designating other ports to help you
troubleshoot mailservers and newsservers quickly.

Then, generally if a webserver isn't answering me, I don't try to
troubleshoot where in the route it is breaking down, but if I were to
investigate that, I would not use a UDP or ICMP tool (unless it worked :-)

That is, if UDP traceroute (normal linux traceroute) works then it is
useful, but if it doesn't it doesn't 'mean anything' because so many
route hops don't echo UDP. At that point one might use an online triple
traceroute such as DNSStuff's which will only tell you how dnsstuff
reaches the target, but not show you how /you/ don't.

Then you know such as what we found about centos site and how its server
doesn't echo anything but TCP and its whole surrounding level3 network
doesn't echo UDP at all, but does do ICMP -- except for centos.

Under those conditions, if you felt like twiddling with it, you could be
using tcptraceroute to locate the problem either geo-wise or
network-wise -- for all the good that will do you since you have no
power over network routing except to use a proxy.

In that condition you can also use an online tool such as Internet
Health Report or internet pulse http://www.internetpulse.net/

Hurricane Electric is a backbone and its biggest adjacencies are Cogent
and Level3 but it has a number of others.

Or, if there was some kind of big latency problem, you could use the
script tool that uses tcptraceroute as tcpping to illustrate the latency.

For webservers, some people like to use a service like 'down for
everyone or just me?' http://www.downforeveryoneorjustme.com/

The point is that your OP doesn't show you using the right tools on your
problem. Sometimes when you can reach something with a proxy it isn't
because there is an 'obstruction' in the network path but because your
name service didn't work properly and the proxy was able to solve the
name problem for you.

--
Mike Easter

[Zen]

Mike Easter wrote:

> I looked in the repoforge index
> http://pkgs.repoforge.org/ and it has tcptraceroute. So you would
> enable the repo in your package manager and then tcptraceroute would be
> listed and you would install it from your package manager.

This worked to install tcptraceroute on Centos 6:
$ sudo yum --enablerepo rpmforge install tcptraceroute -y
Installed:
tcptraceroute.x86_64 0:1.5-0.beta7.el6.rf

$ which tcptraceroute
/usr/bin/tcptraceroute

The interesting thing is that it reports "open" after the exact spot
where the traceroute hung up before (the hop after the errant server).

[Mike Easter]

Zen wrote:

> Mike Easter wrote:

>> So you would
>> enable the repo in your package manager and then tcptraceroute would be
>> listed and you would install it from your package manager.
>
> This worked to install tcptraceroute on Centos 6:

> The interesting thing is that it reports "open" after the exact spot
> where the traceroute hung up before (the hop after the errant server).

Now that you have that tool, I think you should back up/ retreat/ on
your theory of what is going on with trouble with some sites.

In the future, when you have trouble with a site, figure out if your
system is resolving its name and figure out if there is a server there
answering on the appropriate port. I like IDServe for that partly
because it was always handy for me when I was principally Windows. In a
single tool you see the name get resolved and the server get connected
on the appropriate port via TCP.

Most importantly, realize what is wrong with/ limited about/ the default
tools ping and traceroute to help you in such a situation.

There is also a role for 'down for everyone or just me?' sites in the
trouble strategy, so I have it bookmarked.

There are sometimes some funny/odd situations that require using a proxy
to get somewhere, but not very often 'unexpectedly'.

About open: The man page for tcptraceroute explains how it works when
the target sends SYN]ACK and the tool reports it open
http://michael.toren.net/code/tcptraceroute/tcptraceroute.8.html It is
worth noting that tcptraceroute never completely establishes a TCP
connection with the destination host. If the host is not listening for
incoming connections, it will respond with an RST indicating that the
port is closed. If the host instead responds with a SYN|ACK, the port is
known to be open, and an RST is sent by the kernel tcptraceroute is
running on to tear down the connection without completing three-way
handshake. This is the same half-open scanning technique that nmap(1)
uses when passed the -sS flag.


Thus the 'half-open' strategy differs from the strategy employed by
IDServe which is faster because it actually establishes a connection and
response from the server on the designated port.

--
Mike Easter

[Mike Easter]

Mike Easter wrote:

> About open: The man page for tcptraceroute explains how it works

I would also commend to you some valuable information in the
examples.txt file which is included with the install. On my system it
is in /usr/share/doc/tcptraceroute/examples.txt.gz

In that file he shows how to use the tool to access firewalled
webservers and gives examples.

Here is some info about IDServe http://www.grc.com/id/idserve.htm a
simple, free, small (26 kbytes), and fast, general purpose Internet
server identification utility.


--
Mike Easter

[kcGSH6nC]

mtr does what you want.

[Mike Easter]

kcGSH6nC wrote:
> Zen wrote:
>> Trying another web page, the same problem occurs at the very same server!

> mtr does what you want.

Matt's traceroute^1 does its work with ICMP echoes.

On my system, the default traceroute is part of a gname network tools
app gnome-nettool ... http://projects.gnome.org/gnome-network/

That tool's traceroute function uses the default UDP and is not
configurable to use ICMP

... and I haven't installed the freestanding traceroute which is
available in the Ub repos, but that traceroute has the option to use
ICMP packets.

-I Use ICMP ECHO instead of UDP datagrams.


^1 http://www.bitwizard.nl/mtr/index.html After it determines the
address of each network hop between the machines, it sends a sequence
ICMP ECHO requests to each one



--
Mike Easter