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

There is no freeware, or any sort of software available to you, that can help with your problem.

There is a "black hole" between you and centos.org.

Packets go in, but do not come out, that's what the traceroute is telling you.

Contact your ISP, and provide them with the traceroute, they then need to pass that to their (various) upstream connections to get the problem solved.

I would assume that the problem lies with "pnap.net", who- or what-ever they are, but they probably won't talk to you.

Your WISP appears to be connecting to "layer42" (69.36.226.193) as their gateway to the internet, again, they won't talk to you, but your ISP should be able to get them off their arses.

Cheers, Gary B-)

Is it an MTU/fragmentation issue? (Check out ping -M)

Dave

This is exactly what I would have suggested. Data packets have a maximum size dependent on the transport layer carrying them. The default size is typically 1500 for ethernet, and a little less for connections running over PPP and/or VPN. Some long distance WAN links can have even lower maximum packet sizes. If a packet cannot be transmitted in its entirety, it can be split (fragmented) unless the sender has specified that it must not be split. If it can't be split then the sender is responsible for transmitted the data in smaller sized packets, but obviously the sender needs to be informed that the packet size must be reduced. If there's a dubious firewall somewhere between you and the target - one that (incorrectly) eats the ICMP fragmentation request packets - then your sender can't realise that it needs to reduce the packet size, and such packets inevitably get dropped.

You can test this with ping -M, as David Hough has suggested. You can also reduce your own MTU and see whether this "fixes" the problem. Try "ifconfig eth0 mtu 1400", and experiment with different values.

Chris

TCP should be able to find a suitable segment size, but it needs an ICMP message for the functionality. There are sysadmins killing all ICMP, in an attempt to hide from ICMP echo (ping). This could be the cause here.

While I definitely value the help, part of why I am frustrated is that I don't UNDERSTAND the problem, and, as such, I consider ping a diagnostic tool.

The point being, the ping isn't the problem (it's just one way of showing the problem).

So, even if I get the ping to work, it still does nothing to solve the problem (although it may explain a bit).

Since the problem manifests itself in the inability to connect via port 80 (i.e., the web), I have previously doubted the way I'm running ping has anything to do with it.

To me, in my simple mind, trying to get the ping to work is sort of like having an engine misfire, and then I try all sorts of options on my voltmeter to get it to give me a good reading.

Whether or not I get a good reading on the voltmeter, I still have the misfire.

Back to the specifics, whether or not I get a good reading on the ping, I still have the web failing to connect.

I'm not saying ping isn't a great DIAGNOSTIC tool.

I'm just asking how a ping -M is going to help me UNDERSTAND why I can't connect via the web to centos.org?

Nonetheless, in the next post, I'll post my ping results (in the hope that it helps to UNDERSTAND what's going on!).

I'm not sure what an MTU fragmentation issue is, but, if it is related to helping to EXPLAIN why I can't connect via the web to centos.org, I'll be glad to run *any* diagnostic procedure!

Here's the traceroute -M results:

# traceroute -M icmp

Does any of that help diagnose WHY this one IP address times out on port 80 for months on end (and then works just fine for months)?

Hi Chris, I posted my "traceroute -M centos.org" results because I truly want to UNDERSTAND what is going on.

If the problem is that my packets are too large, how does one control that in a web browser?

The ping is merely my diagnostic tool.

The *real* problem is that, for months at a time, I can't connect (via any web browser not on TOR) to:

With TOR, I can connect easily - so it's not the Centos site itself.

QUESTION: How do I control packet size in Firefox?

Hi Chris,

I appreciate your help as I'm trying to UNDERSTAND the problem, which is that, for months on end, I can't connect via the web to

Then, for months at a time, I *can* connect to centos.org, where the traceroute shows the connection going through.

Googling for what an MTU is, I see it's the max size of a packet:

Ethernet has an MTU limit, it appears, of 1500 bytes, so I can see why you're suggesting 1400 bytes.

I don't have much ethernet in the picture though, as I'm on a laptop connected by WiFi to my home broadband router which itself is wired by POE to a rooftop antenna which goes over WiFi about five miles to the WISP antenna where I lose control.

So, I assume you would want me to modify that command: ifconfig eth0 mtu 1400 To: "ifconfig wlan0 mtu 1400

Here's what ifconfig just reported: # ifconfig eth0 Link encap:Ethernet HWaddr 00:a0:00:3a:4f:23 UP BROADCAST MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 B) TX bytes:0 (0.0 B) Interrupt:11 Memory:f2600000-f2620000

wlan0 Link encap:Ethernet HWaddr 00:a0:00:6a:9b:3d inet addr:192.168.1.2 Bcast:192.168.1.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:267437 errors:0 dropped:0 overruns:0 frame:0 TX packets:167343 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:311152648 (296.7 MiB) TX bytes:29413063 (28.0 MiB)

So I ran the following: # ifconfig wlan0 mtu 1400 # ifconfig wlan0 wlan0 Link encap:Ethernet HWaddr 00:a0:00:6a:9b:3d inet addr:192.168.1.2 Bcast:192.168.1.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1400 Metric:1 RX packets:267437 errors:0 dropped:0 overruns:0 frame:0 TX packets:167343 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:311152648 (296.7 MiB) TX bytes:29413063 (28.0 MiB)

And, then I tried to connect via Firefox to centos.org, but it still timed out.

Should I change the mtu even further down, say, to 1000 so that Firefox can connect to

Bearing in mind, the problem is that I'm trying to understand

I set my packet size on my laptop to a low value: # ifconfig wlan0 mtu 500

And, then ran the traceroute: # traceroute -M icmp centos.org traceroute to centos.org (72.232.194.162), 30 hops max, 60 byte packets 1 192.168.1.1 (192.168.1.1) 5.042 ms 5.029 ms 5.017 ms 2 WISP_IP_REDACTED (xxx.xxx.xxx.xxx) 5.022 ms 8.227 ms 8.227 ms 3 10.50.0.1 (10.50.0.1) 13.820 ms 23.623 ms 25.771 ms 4 10.25.0.1 (10.25.0.1) 25.767 ms 30.879 ms 30.877 ms 5 10.20.0.1 (10.20.0.1) 44.616 ms 46.995 ms 46.992 ms 6 10.0.0.1 (10.0.0.1) 52.204 ms 27.862 ms 31.134 ms 7 69.36.226.193 (69.36.226.193) 35.862 ms 50.007 ms 49.971 ms 8 vl2.core1.scl.layer42.net (69.36.225.129) 49.951 ms 74.962 ms 77.875 ms 9 216.156.84.141.ptr.us.xo.net (216.156.84.141) 77.857 ms 25.678 ms 25.643 ms

I'm all for a DIAGNOSTIC approach, since what I'm trying to figure out is WHY the Internet fails me on just one web site.

I just tried it from Knoppix and it is the same result (see below for the details).

I also have tried it from other PC's on the network, running Windows XP and Windows 7, and the same thing occurs.

I also run it via TOR on both Windows & Linux, and it works fine.

So, its clearly not the PC itself. It's in the network - but WHERE?

Anyway, here are the Knoppix results: root@Microknoppix:/# uname -a Linux Microknoppix 3.6.11-64 #10 SMP PREEMPT Wed Dec 19 23:51:48 CET 2012 x86_64 GNU/Linux

root@Microknoppix:/# ifconfig wlan0 mtu 300

root@Microknoppix:/# traceroute -M icmp centos.org traceroute to centos.org (72.232.194.162), 30 hops max, 60 byte packets 1 192.168.1.1 (192.168.1.1) 2.932 ms 2.929 ms 2.928 ms 2 WISP_IP_REDACTED (xxx.xxx.xxx.xxx) 5.683 ms 5.683 ms 5.680 ms 3 10.50.0.1 (10.50.0.1) 20.479 ms 20.477 ms 20.474 ms 4 10.25.0.1 (10.25.0.1) 20.469 ms 30.272 ms 33.014 ms 5 10.20.0.1 (10.20.0.1) 33.009 ms 36.190 ms 36.187 ms 6 10.0.0.1 (10.0.0.1) 36.182 ms 16.332 ms 39.405 ms 7 69.36.226.193 (69.36.226.193) 39.377 ms 20.721 ms 23.093 ms 8 vl2.core1.scl.layer42.net (69.36.225.129) 23.066 ms 16.977 ms 16.947 ms 9 216.156.84.141.ptr.us.xo.net (216.156.84.141) 16.917 ms 12.782 ms 18.611 ms

Get a goot text on TCP/IP protocols and learn how TCP does it. There is an ICMP message 'fragmentation needed but DF bit is on'. The segment auto-sizing is an essential part of TCP.

If a sysadmin has killed the whole ICMP somewhere in the path, there is little you can do, except whine to him.

Traceroute is not of much help here.

You might try traceroute -I centos.org

I'm all for any diagnostic procedure, so, here's the result from Windows 7 trace route:

Microsoft Windows [Version 6.1.7601] Copyright (c) 2009 Microsoft Corporation. All rights reserved.

C:\Users\billy>traceroute -M icmp

C:\Users\billy>tracert

Tracing route to

All this makes perfect sense, except ...

Except my neighbors, on the same WISP, can get to centos.org.

So, it must be something in 'my' setup; but where?

More specifically, how do I diagnose to pinpoint where?

What I don't understand is whether the web browser, which is the problem observed, is using ICMP or TCP.

Q: What is the web browser using? (ICMP? TCP?)

Just so I understand, are you saying that the web (i.e.,

Yes and no.

The data for a website is carried over TCP. The control commands (e.g. "slow down you're filling up the pipe", or "that packet's waayyy too big; make it smaller") are sent over ICMP. Pings and some traceroute programs also use ICMP, but they use a different ICMP message type.

A competently configured firewall might be set up to block ICMP ping requests. But there's no way that same firewall should be completely and naively blocking all ICMP packets.

That's a good starting point, yes. Now you need to see whether your web browser can access centos.org. If it does, increase the MTU until it breaks and then back it off a little.

If it still can't access centos.org, even though you've got your MTU down at 500 then the chances are that this suggestion is inappropriate for your situation.

Chris