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

I have the basic Netgear home broadband router, just like most of you do, and, yes, I have admin as I set it up years ago. Bear in mind that nothing changes on the router that I know of, when this problem comes and goes (for months). But, if there was a particular setting on that router that causes this, I'd love to know what it would be, as mine is set up mostly at default settings (wpa2-psk encryption).

The one thing I have that most of you do not have is I have another radio and antenna on my roof since there are no wires or cables going into my house that contain Internet service (too far from the switch for DSL).

For you, that 'thing' on my roof would be the "modem' and for all intents and purposes, it's the same setup you have, only I get to log into my receiver/transmitter and see what its settings are.

Again, I set it up myself, so, I'm admin there also, and, again, nothing has changed in the two years time that it was set up.

Meanwhile, the ability to connect by the web to centos.org has come and gone over time.

So, while there *could* be a setting in either radio, I wouldn't know where to look since both are set up in the normal configuration for a standard WISP setup.

PS: Where is Jeff Liebermann when you need him! :)

Hi Mike,

So, if the web browser is what is failing, and if the debug commands using TCP also fail, what value is there in everyone saying that ICMP is dropped?

What does ICMP have to do with the web browser failing?

That is, why is everyone suggesting I test ICMP when the failure of the web browser is the problem I'm trying to test?

I don't understand why ICMP has 'anything' directly to do with the web browser failing (other than ICMP also fails).

PLEASE do get a text on TCP, read and understand it. It explains the usage.

ICMP is a helper protocol inside the TCP/IP protocol suite. TCP uses ICMP to detect a suitable segment (transmission block) size.

Your web browser needs UDP for name resolution, TCP for page transfer and ICMP to help TCP work, and all run using IP.

Can you ping the target from your computer?

It works perfectly from here:

--- clip clip ---

tauno-voipios-macbook-pro-2:~ tauno$ ping centos.org PING centos.org (72.232.194.162): 56 data bytes

64 bytes from 72.232.194.162: icmp_seq=0 ttl=52 time=161.925 ms 64 bytes from 72.232.194.162: icmp_seq=1 ttl=52 time=164.736 ms c64 bytes from 72.232.194.162: icmp_seq=2 ttl=52 time=161.303 ms 64 bytes from 72.232.194.162: icmp_seq=3 ttl=52 time=165.196 ms 64 bytes from 72.232.194.162: icmp_seq=4 ttl=52 time=165.483 ms ^C

--- clip clip ---

I can also access the web site with a browser.

BEcause you were also worried about the problem of traceroute failing and/or ping failing.

You could try telnet centos.com 80 (or whatever the address is) to see if there is any response (QUIT should get you out)

eg info:0.0[unruh]>telnet centos.com 80 Trying 87.106.187.200... Connected to centos.com (87.106.187.200). Escape character is '^]'. QUIT

501 Method Not Implemented Method Not Implemented QUIT to /index.html not supported. Connection closed by foreign host. >

You have connection to the web. That is not the problem since you say you can connect to other places. There is something about centos.org that is behaving weirdly. Now it could be something on your end, and it is almost certainly something on their end. They may have decided that you are a pain in the ass and blackballed you (I have no idea why), or it might be some sort of technical incompatibility between you and them. The only way to clear it up is to talk to them about it. If you cannot then I cannot see how you are going to figure it out. Note you could take your computer with you to some other place which connects to the web in some other way than your microwave link and see if that works there.

This is very true.

Maybe it's my fault for bringing up traceroute & ping in the first place; but they're the only freeware tools for debugging the network that I know of.

Clearly they're doing the *same* thing as the web is, which is they're all dying at the penultimate hop before

I did say, in my very first post, that I was pretty sure the problem had nothing to do with the *way* I was running the tools (since the problem is independent of those tools).

$ telnet

80 Trying 72.232.194.162...

The protocols layer and in some cases intertwine. What you call "the web" sits on top of a protocol called HTTP (HyperText Transfer Protocol). HTTP makes use of the services of TCP (Transmission Control Protocol). TCP makes use of IP (Internet Protocol). IP will make use of whatever link-layer protocol is available in its sitaution. For your end systems that will be "Ethernet" protocol over your WiFi connection.

HTTP TCP IP Ethernet/WiFi/whatnot

Within/alongside IP is ICMP (Internet Control Message Protocol). ICMP is used to provide some "Hey, you should know this" kinds of messages back to traffic sources.

So, simplifying a bit, when you try to access

from your web browser, the browser will generate an HTTP message the browswer wants to get to HTTP at That HTTP message will be handed-off to TCP to transmit in one or more TCP segments to TCP at (segment = what a packet is called in the context of TCP). The TCP segment(s) will be handed off to IP, which will encapsulate them in one or more IP datagrams (datagram = what a packet is called in the context of IP) destined to the IP address of IP will then hand its datagrams to the "data link" layer (eg Ethernet etc) which will do its encapsulation. It will then go across the data link destined for IP at the "next hop" where the data-link layer message will decapsulate the IP datagram and hand it to IP at that hop. IP at that hop will then decide what to do with the datagram, which is being sent to the/an IP address for There will probably be another "next hop" and so on until the traffic arrives at IP at will then decapsulate the TCP segment from the IP datagram, and TCP will decapsulate the HTTP message and hand it to the HTTP server.

The HTTP response will flow back to you via a similar mechanism.

Those different lines you see in the output of traceroute are the "next hops" along the way from your system to

Now, the data links at all those next hops may have different limits for how large a packet they can transmit. If an IP datagram arrives at a "next hop" (aka an IP router), and IP there determines that where it needs to be sent-out next is over a data link with a packet size smaller than the IP datagram it needs to send, IP decides to send back to the traffic's source an ICMP message saying "Hey, the datagram you sent is too large for me to send, you should send smaller IP datagrams" (There is more to it than this, but I'm simplifying).

There are other sorts of ICMP "Hey!" messages. One of them is "Maximum Hop Count Reached" - that is the ICMP message that (default) traceroute relies upon receiving. In the header of an IP datagram there is a field called the "TTL" (Time To Live) which is really a maximum hop count. As the IP datagram passes through an IP router, the router decrements the count by one, and when it hits zero, that IP is supposed to send back an ICMP message that says "Hey! The datagram you sent had its maximum hop count expire before it reached its destination." Traceroute works by sending an IP datagram over and over again, with the TTL increased by one each time.

Ping sends a different sort of ICMP message, one that says "Please tell me that you got this" - more formally known as an ICMP Echo Request. The destination IP will send an ICMP Echo Response back to the originator when it receives one.

Now, all these things I've described rely on ICMP messages making it back to the source of the IP/ICMP datagram triggering them. But some network administrators feel that allowing (certain) ICMP traffic to pass represents a security vulnerablity, so they block ICMP traffic.

If ICMP traffic is blocked at a point part-way between you and

you will see the traceroute "stop" (those '*' lines starting indicating there was no response with the TTL set to that many hops). You will also not have ping "work" - it won't see any ICMP Echo Reply messages.

If TCP tries to send a TCP segment that was carried in an IP datagram which needed to be fragmented somewhere in the middle there, then when it goes to send traffic it will appear to disappear - it hits an IP router (next hop) that tried to send it but couldn't and the "Hey!" message that IP router tried to send back was blocked.

Now, by default, ping and traceroute do not send very large IP datagrams, so the chances of those packets arriving at a next hop where fragmentation is needed is pretty small.

Also, not all TCP segments are the same size - the TCP segments used to setup a TCP connection for example are pretty small. That is what was behind some of the "try telnet

80" suggestions - that is an old school way to just try establishing a TCP connection but not actually send any data on it. Those TCP segments will be small.

Why try that? (Or for that matter the pings or traceroutes with options set to send larger packets) Because it is how one tries to see if 'the problem" centers on packets which are too large arriving at a small data link somewhere, or simply a routing issue somewhere in the middle of the Internet. If the "telnet

80" establishes the TCP connection, you can assume that it isn't a routing issue. In that case, a/the remedy is to ensure that TCP at your system and TCP at the system(s) to which you are connecting never try to send TCP segments which become IP datagrams which are too large to send without fragmentation. One can do that by shrinking the MTU of the network interface of your system. When TCP establishes a connection, part of that is exchanging with the other side (eg the Maximum Segment Size (MSS) for the connection. There are several inputs to that exchange, one of which is the MTU of your local interface. The smallest MSS (your's or that of is the one that will be used for traffic in both directions.

Now, if the telnet

80 does not succeed, that means there is some sort of routing issue. That was already partially suggested by the ping and traceroute "failures" you've already reported (if memory serves) but since the ICMP traffic on which they rely can be blocked, their failure is not conclusive.

What sort of routing issue might it be? Well, one could be that there is a simply problem at or after one of those next hops you see in the traceroute output. That is why some have suggested you lookup the information about who runs those and contact them.

It is possible that your source IP has been "black listed" for some reason or other - either at/past the ISP responsible for the last "next hop" you see in traceroute or perhaps even at

Perhaps at one point the IP address you have from your ISP was involved in something considered nefarious or anti-social.

That you could still get to

using TOR would remain consistent with your IP address (the one being assigned to your home gateway by your ISP) being blacklisted because the entire point of TOR (as I understand it) is to hid your actual IP address. It does that by adding some additional layers to the top of what I mentioned above. (As I understand it, I don't actually have any practical experience with TOR).

rick jones

I know it works for you as it works for everyone but me.

1. ping fails every time on
   formatting link
2. traceroute shows the penultimate hop is where it dies It makes no sense.

And, it works for my neighbor, who is on the same WISP. He says my times are longer than his, which is the only delta.

The only thing my neighbor could think of was maybe my transit times are so long that packets are discarded at some point.

I'll bet your transit times are much better than mine, right?

Does *that* transit-time theory make any sense?

Have you been in touch here as suggested by Pooh?

Technical Contact: Internap Network Services Corporation Domain Administrator One Ravinia Drive Suite 1300 Atlanta, GA 30346 US Phone: +1.8778434662 Email: snipped-for-privacy@internap.com

If not, WHY not?

Thanks for that explanation.

What I gather is that the "problem" isn't how I'm running ping or traceroute. The network problem is something more abstract.

Here's what I know:

- I seem to be the only one with this problem.

- It does NOT happen when I go to my neighbor's house using my PC.

- The problem comes and goes (and stays for months).

- Nothing gets past the hop before centos.org.

- I can't go around that penultimate router without using Tor.

- Since TOR works on all the PCs in the house, it's not the PCs. and

- It's not how I'm running the web, traceroute, or ping.

Since the problem seems to be at the penultimate hop, is there any way, other than TOR, to get around that hop (from my own home network)?

Are there public proxies I can set up for Firefox?

The MTU setting made no difference to the web situation. The ONLY things that seem to work are: a) Go to my neighbor's wireless setup b) Use TOR

It's almost as if my IP address is being blocked by that penultimate router.

Is that possible?

I have long ago written to the Centos.org sysadmins, and they confirm there is nothing wrong with my IP address or login account.

(The login works fine and no, there's no reason for them to have blackballed me.)

If it were *that* simple, I wouldn't be asking for networking advice here ... :)

This is not a simple one.

It's not the computer because that same computer works fine at the library and at Starbucks and at a neighbor's house.

The ONLY thing I can think of that's different is a) My IP address (it's static) b) My home broadband router (standard setup) c) My WISP radio (standard setup)

But, all of this is local.

The problem actually seems to occur way down at hop #15, which is beyond my control (far beyond my control).

Is there any way to go around that hop #15?

But he has stated that they all work on other web sites. Only on centos.org do they fail, apparently.

He says he cannot, although he keeps showing the output of traceroute rather than ping.

Yes, he also says that his neighbors have no problem either. So it is something peculiar to the interaction between his machine and that particular site. -- eg firewall on centos which rejects him. Firewall on his side which rejects the far response. (probably he should make sure that all firewalls are disabled and try to contact them, just to rule out the firewall on his machines.)

Well, a firewall might be rejecting you or the reply. Switch off all firewalls-- on your machine, your router, etc to see if that might be the problem.

(switch them on again after the test)

What do you mean "the login works fine"? You told us you could not connect in any way to that machine? Was that wrong?

It is really hard to give help if information supplied is missing or wrong.

Well, no. He tried telnet centos.org 80 which generates no HTTP message. Just a bare connection request. It fails.

He sent really small packets. ping is I believe 80 bytes. And they are not rejecting ping packets (I just checked.)

Except they do not. They come back to me with no trouble. They come back to his neighbour with no trouble.

Yup, but why only to him?

And they failed as well, so I think we can eliminate packet size as an issue.

So, why does the route up to the last hop work, but not that last hop? And why does it work for everyone else. It is really really hard to see it as a routing issue.

Yes, I does look like a firewall issue, but he claims that centos claims that there is no such issue.

Of course it is possible.

>

For you? No. Get in touch with them.

>