traceroute to www.centos.org fails

Al Schmidt

unread,

Feb 28, 2013, 4:21:20 AM2/28/13

to

Any idea why traceroute to www.centos.org fails?
It works at http://www.downforeveryoneorjustme.com/centos.org
But here's the tail end of a Centos 6 traceroute to centos.org.

$ traceroute www.centos.org
...
16 ae-6-6.ebr2.LosAngeles1.Level3.net (4.69.148.201) 87.117 ms ae-3-3.ebr3.Dallas1.Level3.net (4.69.132.78) 87.119 ms ae-6-6.ebr2.LosAngeles1.Level3.net (4.69.148.201) 87.099 ms
17 ae-73-73.csw2.Dallas1.Level3.net (4.69.151.145) 87.089 ms ae-63-63.csw1.Dallas1.Level3.net (4.69.151.133) 77.189 ms ae-3-3.ebr3.Dallas1.Level3.net (4.69.132.78) 74.759 ms
18 ae-73-73.csw2.Dallas1.Level3.net (4.69.151.145) 75.961 ms ae-63-63.csw1.Dallas1.Level3.net (4.69.151.133) 75.974 ms ae-3-80.edge3.Dallas1.Level3.net (4.69.145.136) 75.942 ms
19 LAYERED-TEC.edge3.Dallas1.Level3.net (4.71.170.6) 85.093 ms ae-4-90.edge3.Dallas1.Level3.net (4.69.145.200) 85.043 ms LAYERED-TEC.edge3.Dallas1.Level3.net (4.71.170.6) 85.050 ms
20 LAYERED-TEC.edge3.Dallas1.Level3.net (4.71.170.6) 87.939 ms 87.922 ms 87.899 ms
21 * * *
22 * * *
23 * * *
24 * * *
25 * * *
26 * * *
27 * * *
28 * * *
29 * * *
30 * * *

practice

unread,

Feb 28, 2013, 4:54:13 AM2/28/13

to

On 02/28/2013 03:21, Al Schmidt wrote:
> traceroutewww.centos.org

Works for me

[practice@pcbsd] ~% traceroute www.centos.org
traceroute to www.centos.org (72.232.194.162), 64 hops max, 40 byte packets
1-5...
6 ae5.edge2.dallas3.level3.net (4.68.63.49) 65.881 ms 96.304 ms
66.198 ms
7 ae-4-90.edge3.Dallas1.Level3.net (4.69.145.200) 66.318 ms 66.532 ms
ae-1-60.edge3.Dallas1.Level3.net (4.69.145.8) 66.591 ms
8 LAYERED-TEC.edge3.Dallas1.Level3.net (4.71.170.6) 66.636 ms
66.387 ms 66.191 ms
9 * * *
10 www.centos.org (72.232.194.162) 67.871 ms !Z 66.360 ms !Z 66.423
ms !Z

Richard Kettlewell

unread,

Feb 28, 2013, 4:55:16 AM2/28/13

to

Al Schmidt <as...@notforspam.com> writes:

> Any idea why traceroute to www.centos.org fails?
> It works at http://www.downforeveryoneorjustme.com/centos.org
> But here's the tail end of a Centos 6 traceroute to centos.org.

downforeveryoneorjustme does an HTTP ‘HEAD’ request on a website.
traceroute sends ICMP or UDP packets (usually) with low TTLs and draws
inferences from the error responses. Since they’re exploring quite
different aspects of the target’s behavior, sometimes the outcome
differs.

--
http://www.greenend.org.uk/rjk/

Mike Easter

unread,

Feb 28, 2013, 9:21:42 AM2/28/13

to

Al Schmidt wrote:
> Any idea why traceroute to www.centos.org fails?

The last time centos traceroute was discussed in a.c.f^1, it was
determined that centos does not echo ICMP or UDP pings, only TCP, and
that its associated netblock level3 doesn't echo UDP, but does echo ICMP
and TCP.

Accordingly, depending on what you are trying to find out, you should
use the correct tool for the job.

For example, if you aren't connecting with a website, it is handier to
use something like downforeveryoneorjustme or IDServe (under WINE for
linux). I like IDServe because it shows the name resolving and the
webserver ID/ing.

^1 Long thread at:

http://groups.google.com/group/alt.comp.freeware/browse_thread/thread/89dfc51a1f236947?hl=en

Newsgroups: alt.comp.freeware
Subject: Weirdest thing - need a graphical TRACEROUTE freeware for Linux
(Centos)
Date: Sun, 3 Feb 2013 22:29:18 +0000 (UTC)
Message-ID: <kemobu$56h$1...@solani.org>

--
Mike Easter

Al Schmidt

unread,

Feb 28, 2013, 9:28:47 AM2/28/13

to

Richard Kettlewell wrote on Thu, 28 Feb 2013 09:55:16 +0000:

> traceroute sends ICMP or UDP packets (usually) with low TTLs and draws
> inferences from the error responses. Since they’re exploring quite
> different aspects of the target’s behavior, sometimes the outcome
> differs.

Normally, I can easily get to www.centos.org, but every once in a
while, something weird happens far down into the connection
(at the fifteenth or so hop).

What clued me in was that the web connection, all of a sudden, fails:
http://www.centos.org/traceroute

It gets there via http://traceroute.monitis.com/
http://www5.picturepush.com/photo/a/12301753/img/12301753.png

But not with a telnet to port 80:
$ telnet www.centos.org 80
Trying 72.232.194.162...
telnet: connect to address 72.232.194.162: Connection timed out

A tcptraceroute also fails:
$ sudo tcptraceroute www.centos.org
Selected device wlan0, address 192.168.1.2, port 33715 for outgoing packets
Tracing the path to www.centos.org (72.232.194.162) on TCP port 80 (http), 30 hops max
...
15 ae-6-6.ebr2.LosAngeles1.Level3.net (4.69.148.201) 71.239 ms 72.987 ms 91.560 ms
16 ae-3-3.ebr3.Dallas1.Level3.net (4.69.132.78) 90.449 ms 117.268 ms 98.754 ms
17 ae-73-73.csw2.Dallas1.Level3.net (4.69.151.145) 78.025 ms 75.765 ms 101.761 ms
18 ae-2-70.edge3.Dallas1.Level3.net (4.69.145.72) 65.691 ms 76.246 ms 74.127 ms
19 LAYERED-TEC.edge3.Dallas1.Level3.net (4.71.170.6) 109.142 ms 82.807 ms 78.756 ms
20 * * *

Jasen Betts

unread,

Feb 28, 2013, 5:03:52 AM2/28/13

to

the next step is www.centos.org perhaps it was down?

12 level3-ic-157355-sjo-bb1.c.telia.net (213.248.98.30) 160.077 ms 161.762 ms 162.244 ms
13 vlan70.csw2.SanJose1.Level3.net (4.69.152.126) 207.502 ms 215.274 ms vlan60.csw1.SanJose1.Level3.net (4.69.152.62) 222.462 ms
14 ae-82-82.ebr2.SanJose1.Level3.net (4.69.153.25) 228.935 ms ae-91-91.ebr1.SanJose1.Level3.net (4.69.153.13) 237.066 ms ae-92-92.ebr2.SanJose1.Level3.net (4.69.153.29) 241.804 ms
15 ae-5-5.ebr1.SanJose5.Level3.net (4.69.148.137) 248.136 ms 255.343 ms ae-2-2.ebr2.SanJose5.Level3.net (4.69.148.141) 204.059 ms
16 ae-1-100.ebr2.SanJose5.Level3.net (4.69.148.110) 212.063 ms ae-6-6.ebr2.LosAngeles1.Level3.net (4.69.148.201) 218.247 ms 225.347 ms
17 ae-6-6.ebr2.losangeles1.level3.net (4.69.148.201) 232.472 ms ae-3-3.ebr3.Dallas1.Level3.net (4.69.132.78) 204.046 ms 205.757 ms
18 ae-3-3.ebr3.dallas1.level3.net (4.69.132.78) 211.303 ms 218.068 ms ae-63-63.csw1.Dallas1.Level3.net (4.69.151.133) 245.722 ms
19 ae-2-70.edge3.Dallas1.Level3.net (4.69.145.72) 224.436 ms ae-3-80.edge3.Dallas1.Level3.net (4.69.145.136) 231.922 ms ae-2-70.edge3.dallas1.level3.net (4.69.145.72) 232.133 ms
20 LAYERED-TEC.edge3.Dallas1.Level3.net (4.71.170.6) 238.362 ms 238.866 ms ae-2-70.edge3.dallas1.level3.net (4.69.145.72) 245.324 ms
21 * layered-tec.edge3.dallas1.level3.net (4.71.170.6) 206.294 ms 209.388 ms
22 www.centos.org (72.232.194.162) 209.461 ms !X 215.741 ms !X 205.238 ms !X

--
⚂⚃ 100% natural

--- news://freenews.netfront.net/ - complaints: ne...@netfront.net ---

Al Schmidt

unread,

Feb 28, 2013, 9:31:25 AM2/28/13

to

Mike Easter wrote on Thu, 28 Feb 2013 06:21:42 -0800:

> The last time centos traceroute was discussed in a.c.f^1, it was
> determined that centos does not echo ICMP or UDP pings, only TCP, and
> that its associated netblock level3 doesn't echo UDP, but does echo ICMP
> and TCP.

In layman's terms, what command should I use on Linux to test it?
(an example would be nice so I can duplicate it & report back)

Al Schmidt

unread,

Feb 28, 2013, 9:31:58 AM2/28/13

to

Mike Easter wrote on Thu, 28 Feb 2013 06:21:42 -0800:

> Accordingly, depending on what you are trying to find out, you should
> use the correct tool for the job.

I'd be glad to use the right tool and syntax.

I would welcome a suggestion which I will dutifully repeat & report!

Mike Easter

unread,

Feb 28, 2013, 9:33:46 AM2/28/13

to

Al Schmidt wrote:

> What clued me in was that the web connection, all of a sudden, fails:
> http://www.centos.org/traceroute

centos has no such path.

> But not with a telnet to port 80:
> $ telnet www.centos.org 80
> Trying 72.232.194.162...
> telnet: connect to address 72.232.194.162: Connection timed out

When centos is up telnet works

telnet www.centos.org 80
Trying 72.232.194.162...

Connected to www.centos.org.
Escape character is '^]'.

> A tcptraceroute also fails:

So does tcptraceroute

--
Mike Easter

Al Schmidt

unread,

Feb 28, 2013, 9:40:01 AM2/28/13

to

Mike Easter wrote on Thu, 28 Feb 2013 06:21:42 -0800:

> ^1 Long thread at:

> Newsgroups: alt.comp.freeware
> Subject: Weirdest thing - need a graphical TRACEROUTE freeware for Linux

OK. I see that thread, & I'm trying every Linux example in that thread.

For example, "$ mtr www.centos.org" also dies as shown below:
http://www4.picturepush.com/photo/a/12301812/img/12301812.png

I'm not very fluent but I certainly can copy and paste an example.

Do you have an example command I can run which will show the problem?

Al Schmidt

unread,

Feb 28, 2013, 9:46:30 AM2/28/13

to

Mike Easter wrote on Thu, 28 Feb 2013 06:33:46 -0800:

>> http://www.centos.org/traceroute
>
> centos has no such path.

My mistake. That was a typo. I apologize.

What fails in a browser is:
http://www.centos.org

It worked yesterday and for months prior so all of a
sudden, it doesn't work.

When I checked, by ping, to see why, the ping failed
to return anything (but you mentioned why).
$ ping www.centos.org
PING www.centos.org (72.232.194.162) 56(84) bytes of data.

telnet: connect to address 72.232.194.162: Connection timed out

I'll try any suggested Linux command to see what the problem is!

Al Schmidt

unread,

Feb 28, 2013, 9:50:28 AM2/28/13

to

Mike Easter wrote on Thu, 28 Feb 2013 06:33:46 -0800:

> When centos is up telnet works
>
> telnet www.centos.org 80
> Trying 72.232.194.162...
> Connected to www.centos.org.
> Escape character is '^]'.

That telnet to port 80 works fine to google (for example):
$ telnet www.google.com 80
Trying 74.125.129.104...
Connected to www.google.com.

Escape character is '^]'.

But it just hangs on Centos (which I know is up):

Mike Easter

unread,

Feb 28, 2013, 9:52:02 AM2/28/13

to

Al Schmidt wrote:
> Mike Easter wrote on Thu, 28 Feb 2013 06:21:42 -0800:
>
>> ^1 Long thread at:
>> Newsgroups: alt.comp.freeware
>> Subject: Weirdest thing - need a graphical TRACEROUTE freeware for Linux
>
> OK. I see that thread, & I'm trying every Linux example in that thread.
>
> For example, "$ mtr www.centos.org" also dies as shown below:

mtr uses ICMP. No good for centos echo. mtr can optionally use UDP.
No good for centos.

> Do you have an example command I can run which will show the problem?

What is the problem? centos is up for me.

If you are not connecting from wherever you are because of some problem
between your particular connectivity/network and centos, then you should
use a proxy.

--
Mike Easter

Al Schmidt

unread,

Feb 28, 2013, 9:55:59 AM2/28/13

to

Mike Easter wrote on Thu, 28 Feb 2013 06:52:02 -0800:

> What is the problem? centos is up for me.

That's the problem.
I can get to every other web page I can think of, but,
this one just gets dropped way down in the 15th to 20th hop.

Why the heck would it do that?
More importantly, how the heck can I figure out what the problem is?

Again, I'll run any suggested command, if I only had a command
that would tell me why MY connection to centos.org fails and
everyone elses' connection works fine.

> If you are not connecting from wherever you are because of some problem
> between your particular connectivity/network and centos, then you should
> use a proxy.

I'm installing TOR as we speak and I will report back soon.

Al Schmidt

unread,

Feb 28, 2013, 10:02:27 AM2/28/13

to

Al Schmidt wrote on Thu, 28 Feb 2013 14:55:59 +0000:

> I'm installing TOR as we speak and I will report back soon.

As I had expected, TOR can easily get to www.centos.org
http://www2.picturepush.com/photo/a/12302000/img/12302000.png

This makes sense because the this also worked:
http://traceroute.monitis.com/
http://www5.picturepush.com/photo/a/12301753/img/12301753.png

So, what command could I run to figure out why just 'my'
traceroute/ping/web/telnet/etc connection to www.centos.org
fails all of a sudden (it was working yesterday)?

Mike Easter

unread,

Feb 28, 2013, 10:16:35 AM2/28/13

to

Al Schmidt wrote:

> So, what command could I run to figure out why just 'my'
> traceroute/ping/web/telnet/etc connection to www.centos.org
> fails all of a sudden (it was working yesterday)?

You can't lump all of those together.

When centos is accessible to you, then your browser works as does
anything which uses TCP. It is not helpful to test centos with anything
which expects ICMP or UDP echoes because centos doesn't echo that.

When centos is not accessible to you but is accessible to others, then
the only thing you can do about that is access centos via a proxy. You
are pretty much powerless to repair network problems between you and centos.

If you are trying to diagnose the traceroute issue, then you have to use
tcptraceroute to see centos on the end.

If you feel that it would be useful to discuss centos connectivity
problem with a centos group, my choice would be to access the mailing
list on gmane's news server.

news.gmane.org 119

The news server is 'self authenticating' meaning that you have to use a
good email address. There are a number of centos groups such as
gmane.linux.centos.general

http://gmane.org/post.php

--
Mike Easter

Mike Easter

unread,

Feb 28, 2013, 10:35:05 AM2/28/13

to

Comparing tcptraceroutes:

Al Schmidt wrote:

> A tcptraceroute also fails:
> $ sudo tcptraceroute www.centos.org
> Selected device wlan0, address 192.168.1.2, port 33715 for outgoing packets
> Tracing the path to www.centos.org (72.232.194.162) on TCP port 80 (http), 30 hops max
> ...
> 15 ae-6-6.ebr2.LosAngeles1.Level3.net (4.69.148.201) 71.239 ms 72.987 ms 91.560 ms
> 16 ae-3-3.ebr3.Dallas1.Level3.net (4.69.132.78) 90.449 ms 117.268 ms 98.754 ms
> 17 ae-73-73.csw2.Dallas1.Level3.net (4.69.151.145) 78.025 ms 75.765 ms 101.761 ms
> 18 ae-2-70.edge3.Dallas1.Level3.net (4.69.145.72) 65.691 ms 76.246 ms 74.127 ms
> 19 LAYERED-TEC.edge3.Dallas1.Level3.net (4.71.170.6) 109.142 ms 82.807 ms 78.756 ms
> 20 * * *
> 21 * * *
> 22 * * *
> 23 * * *
> 24 * * *
> 25 * * *
> 26 * * *
> 27 * * *
> 28 * * *
> 29 * * *
> 30 * * *

My tcptraceroute works with/after exactly the same hop as your #19

14 LAYERED-TEC.edge3.Dallas1.Level3.net (4.71.170.6) 46.313 ms 47.293
ms 45.540 ms
15 * * *
16 www.centos.org (72.232.194.162) [open] 46.241 ms 46.375 ms 45.950 ms

--
Mike Easter

Al Schmidt

unread,

Feb 28, 2013, 11:02:05 AM2/28/13

to

Mike Easter wrote on Thu, 28 Feb 2013 07:35:05 -0800:

> My tcptraceroute works with/after exactly the same hop as your #19
>
> 14 LAYERED-TEC.edge3.Dallas1.Level3.net (4.71.170.6) 46.313 ms 47.293
> ms 45.540 ms
> 15 * * *
> 16 www.centos.org (72.232.194.162) [open] 46.241 ms 46.375 ms 45.950 ms
>

I'm confused.
Your words indicate that the tcptraceroute mirrored mine, but the results
you posted indicated the tcptraceroute got to centos.org.

In my case, it never made it to www.centos.org.

Did yours make it to www.centos.org?

Al Schmidt

unread,

Feb 28, 2013, 11:55:24 AM2/28/13

to

Mike Easter wrote on Thu, 28 Feb 2013 07:16:35 -0800:

> You are pretty much powerless to repair network problems
> between you and centos.

I'm confused about two things (which are the same).

Why would this happen (that, just for me), a node (deep
into the net) would just drop 'my' traffic to one site?

How can the Internet work if this happens?

PS: I'll also try that newsgroup but my first attempt failed.

Mike Easter

unread,

Feb 28, 2013, 12:30:52 PM2/28/13

to

Al Schmidt wrote:
> Mike Easter wrote on Thu, 28 Feb 2013 07:35:05 -0800:
>
>> My tcptraceroute works with/after exactly the same hop as your #19
>>
>> 14 LAYERED-TEC.edge3.Dallas1.Level3.net (4.71.170.6) 46.313 ms 47.293
>> ms 45.540 ms
>> 15 * * *
>> 16 www.centos.org (72.232.194.162) [open] 46.241 ms 46.375 ms 45.950 ms

This shows centos on the tcptraceroute after the dallas level3

> I'm confused.

We/You need to define and understand specific scenarios which are variable.

> Your words indicate that the tcptraceroute mirrored mine, but the results
> you posted indicated the tcptraceroute got to centos.org.

I was trying to say that the difference between your traceroute and mine
at the moment we did them showed identical routes except that centos,
the next hop after the dallaslevel3 didn't answer. The first thought
that came to my mind was that the centos webserver was down at the time
you tried yours.

(But) If that were not the case such as that a proxy could connect at
that moment, then (more complex) you would have to believe that the
dallaslevel3 was passing some IP address packets but not others, or else
the webserver at centos was likewise answering some IP address packets
but not others.

> In my case, it never made it to www.centos.org.
>
> Did yours make it to www.centos.org?

Yes of course as the route shows.

You need to 'back up' to eliminate your confusion. When your browser
doesn't get centos, in the past you have used wrong tools to try to find
out why and the use of the wrong tools is confusing you.

In the future, only use good tools. In general, you need to know if the
name is resolving which any number of tools can tell you. You need to
know if something besides your browser can connect with the webserver
such as telnet or tcptraceroute, because other tools won't help you
because centos only answers TCP when it connects. And you need to know
if other routes can reach centos -- all at the same time, not other
times when conditions could change.

--
Mike Easter

Mike Easter

unread,

Feb 28, 2013, 12:50:51 PM2/28/13

to

Mike Easter wrote:

> In the future, only use good tools. In general, you need to know if the
> name is resolving which any number of tools can tell you. You need to
> know if something besides your browser can connect with the webserver
> such as telnet or tcptraceroute, because other tools won't help you
> because centos only answers TCP when it connects. And you need to know
> if other routes can reach centos -- all at the same time, not other
> times when conditions could change.

... and personally, the reason I prefer IDServe over tcptraceroute or
telnet is that I get all the information I want faster.

I am rarely interested in the route hops. I want to see the name
resolve and I want to see the webserver answer. telnet only says
connect. tcptraceroute spends too much time working on information I
don't need. IDServe is very fast, very little, very portable, and very
effective for this, and I use it in both windows and linux.

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:
HTTP/1.1 200 OK
Date: Thu, 28 Feb 2013 17:43:49 GMT
Server: Apache/2.0.52 (CentOS)
X-Powered-By: PHP/4.3.9
Set-Cookie: PHPSESSID=1ffaa2feee29e0b0082805edac3abbcf; path=/
Expires: Mon, 26 Jul 1997 05:00:00 GMT
Cache-Control: private, no-cache
Pragma: no-cache
Connection: close
Transfer-Encoding: chunked
Content-Type: text/html; charset=ISO-8859-1
Query complete.

That shows me the name resolution, the connecting on port 80, and the
webserver's response. So in this type of troubleshooting, I don't need
any other tools.

In your case, if using telnet, tcptraceroute, or IDServe showed you the
name resolving but no connecting on port 80, then you would use a
downforeveryoneorjustme or such as a webproxy - you don't actually need
tor for this, just whatever is handy for you - to see if there is
'discrimination' against your IP or its family or netblock or part of
the internet (or whatever).

But, the answer to that is generally less important than just connecting
-- so if you can connect with a webproxy but not your browser or IDServe
or telnet or tcptraceroute then just do that until such time that you
can connect directly again, the same way you would do if a webserver
were down.

--
Mike Easter

Mike Easter

unread,

Feb 28, 2013, 1:02:06 PM2/28/13

to

Al Schmidt wrote:
> Mike Easter

>> You are pretty much powerless to repair network problems
>> between you and centos.
>
> I'm confused about two things (which are the same).
>
> Why would this happen (that, just for me), a node (deep
> into the net) would just drop 'my' traffic to one site?

On the internet, sh*t happens.

> How can the Internet work if this happens?

We don't comprehensively know for sure what is happening yet.

> PS: I'll also try that newsgroup but my first attempt failed.

Did you read the link I provided about how the gmane server works? It
is not typical. When you (try to) post, your message doesn't just get
posted like a normal news server; you have to reply to an email as
instructed. The docs explain it all.

--
Mike Easter

Al Schmidt

unread,

Feb 28, 2013, 1:10:09 PM2/28/13

to

Jasen Betts wrote on Thu, 28 Feb 2013 10:03:52 +0000:

>> 20 LAYERED-TEC.edge3.Dallas1.Level3.net (4.71.170.6) 87.939 ms 87.922 ms 87.899 ms
>> 21 * * *
>> 22 * * *
>
> the next step is www.centos.org perhaps it was down?
>

> 20 LAYERED-TEC.edge3.Dallas1.Level3.net (4.71.170.6) 238.362 ms 238.866 ms ae-2-70.edge3.dallas1.level3.net (4.69.145.72) 245.324 ms
> 21 * layered-tec.edge3.dallas1.level3.net (4.71.170.6) 206.294 ms 209.388 ms
> 22 www.centos.org (72.232.194.162) 209.461 ms !X 215.741 ms !X 205.238 ms !X

Ah, I had not realized that I was losing the connection in the penultimate hop!

Maybe the Centos.org site is blacklisting blocks of IP addresses and mine is caught up in that?

For the first time, I have an explanation that MIGHT MAKE SENSE!

(It was driving me crazy thinking the Internet is arbitrary.)
I'm positive I've done absolutely nothing that would make that Centos
forum blacklist 'me', so I will ask them if they're implementing IP blocks
that contain my IP address.

Thank you thank you thank you ... now that I know it's the penultimate hop,
I can only assume that it's Centos.org that is dropping the packets, and
not the "Internet", per se.

Does that hypothesis make sense to you?

Al Schmidt

unread,

Feb 28, 2013, 1:16:10 PM2/28/13

to

Mike Easter wrote on Thu, 28 Feb 2013 09:30:52 -0800:

> you would have to believe that the
> dallaslevel3 was passing some IP address packets but not others, or else
> the webserver at centos was likewise answering some IP address packets
> but not others.

Hi Mike,
Thank you VERY MUCH for this information!

I think I finally have a clue as to WHY I periodically can't get to centos.org!

The key datapoint that I had never realized is that I'm losing centos.org
at the penultimate hop, i.e., the last hop before centos.org.

Since we're positive that centos.org is up (I just posted the question on
centos.org via the Tor browser bundle), the problem, as you said, is
either that dallaslevel3 is not passing it onward, or that centos.org
is rejecting it.

What is "dallaslevel3" anyway? Is it connected in any way to Centos.org?

If not, I have to assume they're passing the packets onward.

Armed with the new information that I'm losing the connection at the
penultimate hop, I'm wondering if Centos.org is blacklisting my IP address?

Note: I'm absolutely positive I've done nothing to 'earn' that - but - I
can imagine that they blacklist entire blocks of IP addresses - so - maybe
mine got caught up in the process???

I will contact the administrators at Centos to see if that's the case,
but, what I'd like to ask, specifically, is what is dallaslevel3?

Is it part of centos or is it just one of the many backbone routers on the net?

Al Schmidt

unread,

Feb 28, 2013, 1:17:57 PM2/28/13

to

Mike Easter wrote on Thu, 28 Feb 2013 09:50:51 -0800:

> I prefer IDServe over tcptraceroute or telnet

I'll use whatever tool is recommended.

I did look up IDServe but it seems to be only on Windows:
http://www.grc.com/id/idserve.htm

Al Schmidt

unread,

Feb 28, 2013, 1:26:37 PM2/28/13

to

Mike Easter wrote on Thu, 28 Feb 2013 10:02:06 -0800:

>> PS: I'll also try that newsgroup but my first attempt failed.
>
> Did you read the link I provided about how the gmane server works? It
> is not typical. When you (try to) post, your message doesn't just get
> posted like a normal news server; you have to reply to an email as
> instructed. The docs explain it all.

My second attempt 'appears' to have worked.

I posted via an nntp newsreader to the recommended newsgroup:
gmane.linux.centos.general

I have replied to the authorization email titled:
gmane.linux.centos.general: Authorization required

So, I presume it will post shortly.

I had never heard of "gmane" before, by the way, as I do try to
keep abreast of all the purposefully free nntp USENET public news servers.

The only truly public NNTP servers I knew for NNTP were:
aioe, albasani, news4all, eternal-sept, sunsite, & mixmin

I wonder what gmane adds to the mix?

Mike Easter

unread,

Feb 28, 2013, 1:35:22 PM2/28/13

to

Al Schmidt wrote:

> What is "dallaslevel3" anyway? Is it connected in any way to Centos.org?

centos IP geolocates to (near) that part of .tx

centos IP is in the level3 netblock

> Is it part of centos or is it just one of the many backbone routers on the net?

level3 is backbone and big netblock owner of which centos IP is one
little iota.

--
Mike Easter

Mike Easter

unread,

Feb 28, 2013, 1:46:31 PM2/28/13

to

Al Schmidt wrote:
> Mike Easter

>> I prefer IDServe over tcptraceroute or telnet
>
> I'll use whatever tool is recommended.
>
> I did look up IDServe but it seems to be only on Windows:
> http://www.grc.com/id/idserve.htm

As the IDServe page says, IDServe is free, portable, tiny and fast
assembly code, and also runs on linux under WINE.

There are a few things I like to use with WINE, IDServe, SamSpade,
IrfanView and a few others, so wine is useful to me. Those are all
freeware tools.

In this sequence, just using the tools you have and the knowledge that
some addresses don't answer packets such as ICMP or UDP so TCP is
necessary, the fastest combination would be to see if telnet resolves
the name and connects, then if that failed downforeveryoneorjustme, then
if that connects, a webproxy.

It is of some use to know that the problem is between the last level3
hop and centos, but not very much because you have little or no control
of that, but it might be helpful for you to report it to someone centos
so they can interact with their netblock provider directly or indirectly
through their webservice.

The only thing in this thread about freeware is IDServe and a few other
tools.

--
Mike Easter

Al Schmidt

unread,

Feb 28, 2013, 2:01:01 PM2/28/13

to

Mike Easter wrote on Thu, 28 Feb 2013 10:35:22 -0800:

> level3 is backbone and big netblock owner of which centos IP is one
> little iota.

Well, this finally makes sense once you informed me that the penultimate
hop is where the packets are being stopped.

I don't know if either level3 or centos is blocking my public IP address
but I can ask THEM if they are.

I can't imagine why - but to help figure that out, I just sent a message
to the centos web admins asking whether they're blocking my IP address.

I'm not sure whom to ask at the level3 domain though but running a
reverse IP address lookup for "4.71.170.6" reveals:
Domain Name: LEVEL3.NET
Registrar: MARKMONITOR INC.
Whois Server: whois.markmonitor.com
Referral URL: http://www.markmonitor.com
Name Server: NS1.L3.NET
Name Server: NS2.L3.NET
Status: clientDeleteProhibited
Status: clientTransferProhibited
Status: clientUpdateProhibited
Updated Date: 27-feb-2013
Creation Date: 01-apr-1998
Expiration Date: 31-mar-2014
Contact: 800-745-9229

I called them but nobody picked up at that number so I left a message.

Al Schmidt

unread,

Feb 28, 2013, 2:04:01 PM2/28/13

to

Mike Easter wrote on Thu, 28 Feb 2013 10:46:31 -0800:

> it might be helpful for you to report it to someone centos

I have reported it to the web admin, just a little while ago.
I'll let you know what comes out of that query.

> The only thing in this thread about freeware is IDServe
> and a few other tools.

Centos is freeware too! :)

Mike Easter

unread,

Feb 28, 2013, 2:34:35 PM2/28/13

to

Mike Easter wrote:

> The last time centos traceroute was discussed in a.c.f^1, it was
> determined that centos does not echo ICMP or UDP pings, only TCP, and
> that its associated netblock level3 doesn't echo UDP, but does echo
> ICMP and TCP.

However, re-evaluation at this time reveals that centos will now echo
ICMP and TCP (but not UDP), like the rest of the level3 network it is
associated.

That was also noted by a poster in the gmane centos group.

That also means that the mtr tool will work to reach centos in its
default ICMP mode, but not -u UDP.

--
Mike Easter

Message has been deleted

Al Schmidt

unread,

Feb 28, 2013, 6:44:32 PM2/28/13

to

Derald wrote on Thu, 28 Feb 2013 18:29:17 -0500:

>>Any idea why traceroute to www.centos.org fails?
> It doesn't

Heh heh.

It does for me.

:)

unread,

Mar 1, 2013, 10:33:18 AM3/1/13

to

Al Schmidt wrote on Fri, 01 Mar 2013 01:18:10 +0000:

Mike Easter wrote on Thu, 28 Feb 2013 16:54:22 -0800:
> I think it is more likely to be 'an accident' of some sort

Here is more data gathered from the gmane group & from friends!

> It is worth noting that www.centos.org was inaccessible from Serbia and
> http://www.downforeveryoneorjustme.com/centos.org on 27.01.2013 around
> 16:30, for about 1-2 hours.

I can see pretty bad connectivity for Centos.org over here:
http://www.isitdownrightnow.com/centos.org.html

Here's a screenshot of the results:
http://www1.picturepush.com/photo/a/12306664/img/12306664.png

I'm not on any of these blacklists:
http://multirbl.valli.org
http://www.lookinglass.org

In addition, I had asked some friends, who reported back:
APPLE:
> For what it is worth I can't get to centos.org from Apple's network
> either. The traceroute finally gets through after 42 hops but the
> servers are dropping the connection immediately.
> Me thinks it is a centros.org problem and not an ISP issue.

MAXIM:
> Ha - just checked. I can't to centos from Maxim either.

GOOGLE:
> Centos works OK for me from google, as long as I spell it right!

A neighborly friend tested similar situations:
> While it is possible that the laptop had a temporary problem wherein
> it had set the TimeToLive (TTL) of the packets to 19, that also seems
> like a long shot.
>
> However, trying a reboot if/when it happens again to rule out laptop
> fatigue is another test to try. Also, finding a site that has more
> than 20 hops would also be a test of that. It turns out it isn't all
> that easy to find a site with that many hops. Traceroute deliberately
> plays with the TTL number, so it would seem like a long shot if
> traceroute also showed the problem, as it does in this case.
>
> Nonetheless, if it happens again, try a traceroute to tempotv.com.tr,
> which takes 23 hops from my computer.
>
> I can get to Iran in 24 hops: traceroute www.gu.ac.ir.
> On the Internet, centos.org is as far away as Pakistan:
> traceroute www.gu.edu.pk.
>
> Some routers drop ICMP packets when they get busy, or rate-limit
> the replies. You could have been trying to get to centos.org while
> they were being hit by a DDOS attack. Routers would automatically
> drop whole blocks of IPs for a short while to cope with the problem.
>
> ...and just for fun, let's try Malaysia:
>
> C:\temp>tracert -h 255 www.tourism.gov.my
>
> Tracing route to www.tourism.gov.my [168.63.252.50]
> over a maximum of 255 hops:

So, maybe it is Centos, in general, instead of Centos, for me???

Al Schmidt

unread,

Mar 1, 2013, 11:22:13 AM3/1/13

to

Al Schmidt wrote on Fri, 01 Mar 2013 15:33:18 +0000:
>> try a traceroute to tempotv.com.tr,
>> which takes 23 hops from my computer.
>>
>> I can get to Iran in 24 hops: traceroute www.gu.ac.ir.
>> On the Internet, centos.org is as far away as Pakistan:
>> traceroute www.gu.edu.pk.

The interesting thing is that the results above were from
a neighbor using the same WISP!

Yet, here are my results of those long-hop destinations just now:

$ traceroute tempotv.com.tr ==> died on the 23rd hop
$ traceroute -I www.centos.org ==> died on the 19th (penultimate) hop
$ traceroute www.gu.ac.ir ==> Iran, died on the 22nd hop
$ traceroute www.gu.edu.pk ==> Pakistan, made it only to the 19th hop
$ traceroute -m 255 www.tourism.gov.my ==> Malaysia died on the 19th hop

All the above died before reaching their destinations.

Mike Easter

unread,

Mar 1, 2013, 11:37:35 AM3/1/13

to

Don't forget that a lot of traceroute tools use UDP which centos doesn't
echo.

You have a mtr which uses ICMP by default which is better than using a
traceroute if you don't know whether it is ICMP, UDP, or TCP.

My linux ping is also ICMP which centos answers now and is quick.

--
Mike Easter

Jasen Betts

unread,

Mar 1, 2013, 12:29:23 AM3/1/13

to

# tcptraceroute www.centos.org
Selected device eth3, address 192.168.2.2, port 45018 for outgoing

packets
Tracing the path to www.centos.org (72.232.194.162) on TCP port 80

(www), 30 hops max
1 www.centos.org (72.232.194.162) [open] 0.330 ms 0.316 ms 0.270 ms

um, perhaps I should try it somewhere that's not running a
transparent proxy :)

11 ae-3-80.edge3.Dallas1.Level3.net (4.69.145.136) 36.018 ms 35.278
ms ae-4-90.edge3.Dallas1.Level3.net (4.69.145.200) 33.784 ms
12 LAYERED-TEC.edge3.Dallas1.Level3.net (4.71.170.6) 43.598 ms
43.575 ms 41.763 ms
13 * * *
14 www.centos.org (72.232.194.162) 35.801 ms 36.249 ms 35.950 ms

on port 80 there's something between LAYERED-TEC and www.centos.org
a load balancer perhaps, it's there on port 443 too.

--
⚂⚃ 100% natural

--- news://freenews.netfront.net/ - complaints: ne...@netfront.net ---