Frustrated that I don't UNDERSTAND why my network times out

Login? Are you talking about login here?

The difference between http and https protocols is the layering of http over the SSL/TLS protocol and the other difference is the use of port

Or perhaps you are talking about logging in to some other server - the centos forums are at https centos as well.

The bugs.centos server login is at a different IP 83.149.86.133

Which was why I suggested telnet centos.org 80 but that did not return anything for him. Everyone else in the world has no trouble connecting but he does and he wants to know why.

That's a perfect summary! I can't imagine that I'm singled out in this world for not connecting, for months at a time, to centos.org (it happened with one other web site - but it was so long ago that I've forgotten which it was).

One question I have is WHICH site is dropping my packets?

Is it the last site that returns traceroute values? Os is it the first site that has all asterisks?

# traceroute -M icmp

Is it hop 15 or 16 above which is dropping my packets?

All I do, on TOR, is type '

Then, for months at a time, I can't even connect to

When I run a traceroute (any type of traceroute), the result is that the last hop before centos.org is the last hop that returns anything. The centos.org hop is asterisked out.

There's absolutely nothing wrong with my login (I easily log in with TOR, and I have an old thread asking THEM what's going on, and they don't know either).

So, I 'think' it's the ISP that they use.

I remember having a similar problem with telephones not being able to call certain numbers, and, we found out it was a routing thing at the Ooma headquarters. Nobody on the planet could call these specific numbers, one of whom was a relative of mine so I knew that the number existed. Yet, nobody could call the number from VOIP.

Same kind of idea seems to be here. Some router somewhere is very badly set up.

The funny thing, is that I'm the only one with the problem. Worse yet, there are no debugging tools for when a router is dropping packets. That's the saddest part.

I've been trying to solve this for two years running. Or, at least understand how it could possibly happen.

When I point my browser to http://83.149.86.133 I get the message: Forbidden You don't have permission to access / on this server. Apache/2.2.3 (CentOS) Server at 83.149.86.133 Port 80

# telnet 83.149.86.133 80 Trying 83.149.86.133... Connected to 83.149.86.133. Escape character is '^]'. HEAD HTTP/1.0

# traceroute -M icmp 83.149.86.133 # traceroute -M icmp 83.149.86.133 traceroute to 83.149.86.133 (83.149.86.133), 30 hops max, 60 byte packets 1 192.168.1.1 (192.168.1.1) 3.423 ms 3.405 ms 6.261 ms 2 MY_WISP_ADDRESS (xx.xx.xx.xx) 9.844 ms 9.842 ms 9.839 ms 3 10.50.0.1 (10.50.0.1) 15.284 ms 139.930 ms 139.937 ms 4 10.25.0.1 (10.25.0.1) 148.735 ms 148.734 ms 148.729 ms 5 10.20.0.1 (10.20.0.1) 164.306 ms 169.567 ms 169.564 ms 6 10.0.0.1 (10.0.0.1) 344.049 ms 70.997 ms 189.575 ms 7 69.36.226.193 (69.36.226.193) 189.531 ms 34.070 ms 136.902 ms 8 vl2.core2.scl.layer42.net (69.36.225.130) 139.000 ms 47.370 ms

So, I have absolutely no problem getting to this site. But, why would I have a problem getting to centos.org?

Could it be that anything after 15 hops fails no matter what? To test, do you know of a site that would be more than 15 hops away from San Francisco, CA?

I'm beginning to wonder if anything after about 15 hops is dropping the connection for me?

Could it be that the path to centos.org just happens to be longer than any other path I've tried?

The path to the centos bug server you gave me worked fine, but it only took 15 hops.

Do you have a way for me to pick somewhere far far away from San Francisco CA to see if it's simply the long path that is causing the problem (i.e., more than 16 hops)?

I will contact them at the email addresses already posted and ask them if they're periodically doing something nasty to my IP address for months at a time (like putting me on a blacklist or something).

I'll report back if/when they respond.

Everything you said is right on the money. It's frustratingly hard to figure out.

The only two ideas "I" can come up with are:

1. Someone is blocking me (but I can't imagine why)
2. The path is too long for something (but I don't know what).

In the first case, I'm not sure if the blocker would be the

In the second case, it would be useful to test a similarly long (at least 16 hops) path. Or, maybe there's a way to slow down my pings so that I can reproduce the problem in fewer hops?

I understand and agree with your use of "claims", as you don't know what I've been told.

I can google for the public thread where I asked them (and they responded in email privately also) and point you to that. It was about six months to a year ago.

Gimme a minute to find it (Google will find it but I won't be able to open it up - but you should be able to).

OK. Found it with Google on CentOS.org Title: What can I do to UNDERSTAND why

Of course, I can't "go" to that URL (since it's on CentOS.org) but it looks like it's mirrored here: linuxreference.com/modules/newbb/viewtopic.php?topic_id=41677&forum=55

Hey! Guess what? I can't get to "linuxreference.com" either! Just like centos.org, it goes to asterisks on the 16th hop!

I'm getting tired of redacting my IP address, so I'm letting it show here. I hope I don't regret that! :)

# traceroute -M icmp linuxreference.com traceroute to linuxreference.com (72.232.194.162), 30 hops max, 60 byte packets 1 192.168.1.1 (192.168.1.1) 2.851 ms 2.836 ms 2.839 ms 2 67-218-118-85.ridgewireless.net (67.218.118.85) 5.849 ms 5.849 ms

I can google just fine, so I found the original request way back in March on the Centos site (I subsequently got an email from the admins saying there's nothing wrong with my IP address).

Here's what Google says the Centos article URL is:

It's looking more and more like anything longer than about 15 hops is dying for me. At least that's a preliminary guess.

Notice I can get to this Centos mirror just fine:

When I traceroute to it, I see a MUCH SHORTER route!

# traceroute -M icmp

IIRC, when I had asked my neighbors, they had fewer hops to the same destination - so - I'm beginning to wonder if it's the sheer number of hops (or the time involved); but that's just a guess.

I'd be glad to post traceroute or ping results to ANY server you suggest, so we can compare with you.

I'll also ask a neighbor to send me his traceroutes and post them when/if I get them.

I have sent all the email addresses on that list an email. I will write back if/when they respond. I don't have high hopes that they will - but - they might.

I gave them the unedited traceroute results just like I gave you.

The ping is useless. Either that or I'm using it wrong.

Here's the cut and paste for the pings on Knoppix: # ping -M icmp centos.org ping: wrong value for -M: do, dont, want are valid ones.

# ping --help ping: invalid option -- '-' Usage: ping [-LRUbdfnqrvVaAD] [-c count] [-i interval] [-w deadline] [-p pattern] [-s packetsize] [-t ttl] [-I interface] [-M pmtudisc-hint] [-m mark] [-S sndbuf] [-T tstamp-options] [-Q tos] [hop1 ...] destination

# # ping

^C

---

(strangely it took minutes to time out on Knoppix so I killed it).

I was, perhaps, being overly simplistic in my use of terms. I was lumping-in "classic" routing issues like loops and what not in with things like deliberate blacklisting.

Anywhere between that 15th hop in the traceroute and centos.org I would think.

That it comes and goes for months at a time has me wondering about the rate at which his ISP might be changing his assigned IP address (the one his gateway gets), and whether or not the "blackouts" correlated with that. That would require having kept a log of the noticed start and end of the blackouts and a log of the IP assigned by the ISP.

rick jones

Your basic problem in this entire discussion is that you have no concept of the very basics in networking - called - a protocol stack -

Here is the TCP/IP version -

Application (like email, browser, etc) Transport (specify ports on computers) Internet (addressing & routing) Link (physical)

The browser lives at the very top - as an Application and has NO knowledge of ANY protocol issues at the lower layers. So, to keep asking about how the fix the browser is meaningless.

The lower layers are where TCP (Transport Control Protocol) and the IP (Internet Protocol) address live.

Next - is the physical and link.... this is the magic of "transmit" and "receive" -

SO - some routers and website might turn of their responses to ICMP messages (ping/echo etc) and it might appear they are not responding to those tools - but in fact - they are "ignoring" them.

On the topic of MTU (the size of the packets transmitted) I have never had a website not respond, but have had probs with a school system called Blackboard that would not function properly on a DSL line due to a MTU being less than the Blackboard required value of 1500.

WEIRD - I can ping and traceroute to --> centos.org but it does NOT reply to my browser request ??

This page cannot be displayed due to an internal error.

If you are the administrator of this site, please visit the Xoops Troubleshooting Page for assistance.

Error [Xoops]: Unable to connect to database in file class/database/databasefactory.php line 34

it times out - done -

Presently centos.org is down for everyone

That has not been the case for the duration of this thread.

Initiating server query ... Looking up IP address for domain:

He may not have, but it is irrelevant. He is not able to connect. Can you give him the cause? Can you suggest how he fix it? It is like if you brought me your car to fix and I told you that you had no concept of the basics of the Standard Model of particle phyics as if such knowledge would help you fix your car.

And you now call this weird. I thought you had an intimate knowledge of the protocol layers. Why is this weird?

Note that I have absolutely no trouble connecting to centos.org.

I have.

Chris