Can't get to metafilter from my ISP January 2, 2008 4:25 PM Subscribe
I can't get to any metafilter.com addresses from my home ISP. I can get to it from other places, i.e. work, and I can get to it if I use an open proxy.
More details inside.
Traceroutes basically look like this:
It's not the worst problem in the world, but it's annoying and somewhat puzzling.
Traceroutes basically look like this:
[entries 1 to 5, leaves my router, goes through the ISP, goes through the Australian hub]6. <something>.theplanet.com7. <somethingelse>.theplanet.com8. <somethingelseagain>.theplanet.com[entries 9 to 64 all say '* * * *']Then it times out after 64 hops.
It's not the worst problem in the world, but it's annoying and somewhat puzzling.
I get the same result, and I can reach metafilter. I assume the next hop simply isn't letting the traceroute through, that's not that uncommon.
theplanet hops:
theplanet hops:
14 te7-1.dsr02.dllstx3.theplanet.com (70.87.253.18) 56.930 ms 56.015 ms te9-1.dsr01.dllstx3.theplanet.com (70.87.253.6) 56.533 ms 15 76.fd.5746.static.theplanet.com (70.87.253.118) 56.852 ms 56.436 ms 56.891 ms 16 po1.car05.dllstx6.theplanet.com (12.96.160.7) 73.461 ms 80.239 ms 60.696posted by mendel at 7:43 PM on January 2, 2008
I think you're going to have to try some additional diagnostics. I can get to metafilter fine, but from a quick check with traceroute it appears that a UDP traceroute is filtered inside theplanet.com's network. However, I get a successful traceroute with an ICMP traceroute:
posted by RichardP at 8:02 PM on January 2, 2008
~ $ traceroute -P icmp www.metafilter.com
traceroute to metafilter.com (74.53.68.130), 64 hops max, 60 byte packets
[snip]
5 dalsbbrj02-ae0.r2.dl.cox.net (68.1.0.143) 52.750 ms 53.739 ms 53.537 ms
6 vl32.dsr02.dllstx3.theplanet.com (70.85.127.62) 53.464 ms 52.650 ms 53.140 ms
7 7e.fd.5746.static.theplanet.com (70.87.253.126) 57.645 ms 53.886 ms 56.079 ms
8 po2.car05.dllstx6.theplanet.com (12.96.160.39) 53.906 ms 56.072 ms 57.123 ms
9 82.44.354a.static.theplanet.com (74.53.68.130) 61.923 ms 57.547 ms 63.895 ms
10 82.44.354a.static.theplanet.com (74.53.68.130) 71.382 ms 89.054 ms 76.479 ms
~ $ traceroute www.metafilter.com
traceroute to metafilter.com (74.53.68.130), 64 hops max, 40 byte packets
[snip]
6 vl32.dsr02.dllstx3.theplanet.com (70.85.127.62) 54.006 ms 52.277 ms 53.218 ms
7 7e.fd.5746.static.theplanet.com (70.87.253.126) 158.327 ms 202.187 ms 211.645 ms
8 po2.car05.dllstx6.theplanet.com (12.96.160.39) 54.245 ms 54.311 ms 53.858 ms
9 * * *
[snip]posted by RichardP at 8:02 PM on January 2, 2008
How many hops with the asterisks though, mendel? My traceroute (OS X 10.4) specifically says it's limited to 64.
posted by AmbroseChapel at 8:02 PM on January 2, 2008
posted by AmbroseChapel at 8:02 PM on January 2, 2008
What are the further diagnostics I should get, RichardP?
posted by AmbroseChapel at 8:04 PM on January 2, 2008
posted by AmbroseChapel at 8:04 PM on January 2, 2008
What are the further diagnostics I should get, RichardP?
AmbroseChapel, could you post the results of an ICMP traceroute? The first command in my example, i.e. "traceroute -P icmp www.metafilter.com" is the appropriate command line for Mac OS X and other BSD derivatives. I think "traceroute -I www.metafilter.com" is the appropriate command for Linux. I don't know the command for any of the flavors of Windows.
Does your home ISP use some sort of transparent web proxy that might be interfering with web traffic to metafilter? If you don't know, you could try this proxy detection tool, but it isn't 100% reliable.
posted by RichardP at 8:15 PM on January 2, 2008
AmbroseChapel, could you post the results of an ICMP traceroute? The first command in my example, i.e. "traceroute -P icmp www.metafilter.com" is the appropriate command line for Mac OS X and other BSD derivatives. I think "traceroute -I www.metafilter.com" is the appropriate command for Linux. I don't know the command for any of the flavors of Windows.
Does your home ISP use some sort of transparent web proxy that might be interfering with web traffic to metafilter? If you don't know, you could try this proxy detection tool, but it isn't 100% reliable.
posted by RichardP at 8:15 PM on January 2, 2008
I'll try it later from home. Thanks.
posted by AmbroseChapel at 8:17 PM on January 2, 2008
posted by AmbroseChapel at 8:17 PM on January 2, 2008
From a Windows DOS prompt: "tracert www.metafilter.com >trace.txt":
posted by Steven C. Den Beste at 11:28 PM on January 2, 2008
Tracing route to www.metafilter.com [74.53.68.130] over a maximum of 30 hops: 1 <1> 2 * * * Request timed out. 3 9 ms 9 ms 9 ms GE-1-2-ur03.beaverton.or.bverton.comcast.net [68.87.218.9] 4 8 ms 9 ms 11 ms te-9-1-ur04.beaverton.or.bverton.comcast.net [68.87.216.50] 5 22 ms 9 ms 8 ms te-8-4-ur05.beaverton.or.bverton.comcast.net [68.87.216.101] 6 7 ms 9 ms 9 ms te-9-1-ur06.beaverton.or.bverton.comcast.net [68.87.216.98] 7 10 ms 9 ms * te-7-4-ar01.troutdale.or.bverton.comcast.net [68.87.216.106] 8 17 ms 14 ms 13 ms COMCAST-IP.car1.Seattle1.Level3.net [4.79.104.106] 9 17 ms 14 ms 13 ms te-3-2.car1.Seattle1.Level3.net [4.79.104.105] 10 14 ms 16 ms 16 ms ae-31-51.ebr1.Seattle1.Level3.net [4.68.105.30] 11 18 ms 18 ms 17 ms ae-1-100.ebr2.Seattle1.Level3.net [4.69.132.18] 12 56 ms 53 ms 53 ms ae-2.ebr2.Denver1.Level3.net [4.69.132.54] 13 44 ms 42 ms 47 ms ae-1-100.ebr1.Denver1.Level3.net [4.69.132.37] 14 59 ms 55 ms 55 ms ae-2.ebr2.Dallas1.Level3.net [4.69.132.106] 15 60 ms 55 ms 56 ms ae-82-82.csw3.Dallas1.Level3.net [4.69.136.146] 16 59 ms 56 ms 56 ms ae-34-89.car4.Dallas1.Level3.net [4.68.19.134] 17 56 ms 56 ms 54 ms THE-PLANET.car4.Dallas1.Level3.net [4.71.122.2] 18 56 ms 57 ms 56 ms te7-2.dsr02.dllstx3.theplanet.com [70.87.253.26] 19 55 ms 57 ms 59 ms 72.fd.5746.static.theplanet.com [70.87.253.114] 20 58 ms 75 ms 58 ms po1.car05.dllstx6.theplanet.com [12.96.160.7] 21 63 ms 70 ms 64 ms 82.44.354a.static.theplanet.com [74.53.68.130] 22 66 ms 63 ms 61 ms 82.44.354a.static.theplanet.com [74.53.68.130] Trace complete.
posted by Steven C. Den Beste at 11:28 PM on January 2, 2008
(Grumble; damned thing double-spaced even though I went in and deleted all the excess newlines grumble. Sorry about that.)
posted by Steven C. Den Beste at 11:29 PM on January 2, 2008
posted by Steven C. Den Beste at 11:29 PM on January 2, 2008
SCDB: that's what the
Compare this comment to this one, the first is using
posted by philomathoholic at 1:09 AM on January 3, 2008
<pre> tag does (at least here at mefi, I don't know about elsewhere). Try the <code> tag. Compare this comment to this one, the first is using
<pre>, the other is using <code>.posted by philomathoholic at 1:09 AM on January 3, 2008
Yes, <pre> does that.
Also, what on earth was the point of it? Are you having problems connecting, SCDB?
Here's the result of the icmp:
posted by AmbroseChapel at 2:56 AM on January 3, 2008
Also, what on earth was the point of it? Are you having problems connecting, SCDB?
Here's the result of the icmp:
traceroute -P icmp www.metafilter.com
traceroute to metafilter.com (74.53.68.130), 64 hops max, 60 byte packets
1 mygateway1.ar7 (192.168.1.1) 2.180 ms 0.781 ms 0.674 ms
2 149.1.233.220.exetel.com.au (220.233.1.149) 35.474 ms 19.678 ms 18.038 ms
3 * * *
4 10.0.1.2 (10.0.1.2) 22.281 ms 47.524 ms 18.855 ms
5 34.2.233.220.exetel.com.au (220.233.2.34) 18.788 ms 18.641 ms 45.927 ms
6 vlan366.o2gsc76f03.optus.net.au (203.202.84.65) 24.845 ms 19.565 ms 34.607 ms
7 208.50.13.165 (208.50.13.165) 174.523 ms 175.236 ms 185.573 ms
8 the-planet.gigabitethernet7-3.ar2.dal2.gblx.net (64.208.170.198) 221.347 ms 219.493 ms 220.055 ms
9 te9-2.dsr01.dllstx3.theplanet.com (70.87.253.14) 220.602 ms 222.064 ms 221.736 ms
10 72.fd.5746.static.theplanet.com (70.87.253.114) 223.401 ms 220.814 ms 220.175 ms
11 po1.car05.dllstx6.theplanet.com (12.96.160.7) 223.373 ms po2.car05.dllstx6.theplanet.com (12.96.160.39) 223.700 ms 221.789 ms
12 www.metafilter.com (74.53.68.130) 224.658 ms 222.559 ms 221.110 ms
13 www.metafilter.com (74.53.68.130) 221.427 ms 222.002 ms 222.921 msposted by AmbroseChapel at 2:56 AM on January 3, 2008
...and here's a regular traceroute without the flags:
posted by AmbroseChapel at 3:09 AM on January 3, 2008
traceroute to metafilter.com (74.53.68.130), 64 hops max, 40 byte packets
1 mygateway1.ar7 (192.168.1.1) 1.716 ms 0.664 ms 8.567 ms
2 149.1.233.220.exetel.com.au (220.233.1.149) 19.028 ms 32.612 ms 50.083 ms
3 * * *
4 10.0.1.2 (10.0.1.2) 31.525 ms 18.199 ms 16.969 ms
5 34.2.233.220.exetel.com.au (220.233.2.34) 22.191 ms 18.214 ms 19.144 ms
6 vlan366.o2gsc76f03.optus.net.au (203.202.84.65) 30.803 ms 20.910 ms 19.711 ms
7 208.50.13.185 (208.50.13.185) 174.277 ms 175.375 ms 175.385 ms
8 the-planet.gigabitethernet7-3.ar2.dal2.gblx.net (64.208.170.198) 251.864 ms 225.503 ms 221.405 ms
9 te7-2.dsr01.dllstx3.theplanet.com (70.87.253.10) 221.199 ms te7-2.dsr02.dllstx3.theplanet.com (70.87.253.26) 215.851 ms 216.816 ms
10 7e.fd.5746.static.theplanet.com (70.87.253.126) 220.146 ms 220.331 ms 221.493 ms
11 po2.car05.dllstx6.theplanet.com (12.96.160.39) 239.039 ms 235.460 ms 220.547 ms
12 * * *
[snip lots of lines which just read '* * *']
64 * * *
posted by AmbroseChapel at 3:09 AM on January 3, 2008
And for the record, the proxy detection tool detects nothing. And when I try to go to metafilter, the browser (Firefox) just stays on "loading" for a really long time. It's been about twenty minutes so far and it hasn't timed out, in case that means something.
posted by AmbroseChapel at 3:23 AM on January 3, 2008
posted by AmbroseChapel at 3:23 AM on January 3, 2008
AmbroseChapel, given that it isn't a DNS problem (since www.metafiter.com resolves for you at home), it isn't a routing problem (the ICMP traceroute works fine), and probably not a malfunctioning transparent proxy (negative result from the proxy detection tool), perhaps it's an MTU problem somewhere in the network path?
As an experiment, try comparing the results of ping using a small packet size and a large packet size:
If you get different results from those two commands on your Mac your problem is probably broken path-MTU discovery due to erroneous ICMP filtering (also here) somewhere in either your network, your ISPs network, Metafilter's network, or at Metafilter's host. If this is the case (and assuming the Mac is connected via Ethernet), try the following as a fix:
posted by RichardP at 10:11 AM on January 3, 2008
As an experiment, try comparing the results of ping using a small packet size and a large packet size:
~ $ ping -c 4 www.metafilter.com
PING metafilter.com (74.53.68.130): 56 data bytes
64 bytes from 74.53.68.130: icmp_seq=0 ttl=119 time=54.013 ms
64 bytes from 74.53.68.130: icmp_seq=1 ttl=119 time=59.794 ms
64 bytes from 74.53.68.130: icmp_seq=2 ttl=119 time=53.692 ms
64 bytes from 74.53.68.130: icmp_seq=3 ttl=119 time=61.263 ms
--- metafilter.com ping statistics ---
4 packets transmitted, 4 packets received, 0% packet loss
round-trip min/avg/max/stddev = 53.692/57.191/61.263/3.380 ms
~ $ ping -c 4 -D -s 1472 www.metafilter.com
PING metafilter.com (74.53.68.130): 1472 data bytes
1480 bytes from 74.53.68.130: icmp_seq=0 ttl=119 time=56.515 ms
1480 bytes from 74.53.68.130: icmp_seq=1 ttl=119 time=56.902 ms
1480 bytes from 74.53.68.130: icmp_seq=2 ttl=119 time=55.692 ms
1480 bytes from 74.53.68.130: icmp_seq=3 ttl=119 time=57.447 ms
--- metafilter.com ping statistics ---
4 packets transmitted, 4 packets received, 0% packet loss
round-trip min/avg/max/stddev = 55.692/56.639/57.447/0.639 ms
If you get different results from those two commands on your Mac your problem is probably broken path-MTU discovery due to erroneous ICMP filtering (also here) somewhere in either your network, your ISPs network, Metafilter's network, or at Metafilter's host. If this is the case (and assuming the Mac is connected via Ethernet), try the following as a fix:
- From the Apple menu, choose System Preferences.
- Select the Network pane.
- From the Show pop-up menu, choose Built-in Ethernet.
- Click the Ethernet tab.
- From the Configure pop-up menu, choose Manually (Advanced).
- For Maximum Packet Size (MTU) select the radio button labeled Custom.
- In the field to the right of Custom, enter a new value lower than 1500 - I'd try 1492 or perhaps 1480.
posted by RichardP at 10:11 AM on January 3, 2008
Looks like you need to reinitialize your flux vector. If that doesn't work, try pulling the Electrodynamometer and cleaning the bushings, and relubricate your transformatic snarkification rod with weasel grease, and realign it to 42.76 degrees postvectoral*.
* not responsible for space-time ruptures resulting from this alignment.
posted by blue_beetle at 11:39 AM on January 3, 2008
* not responsible for space-time ruptures resulting from this alignment.
posted by blue_beetle at 11:39 AM on January 3, 2008
RichardP beat me to it; this sounds precisely like the MTU fragmentation problem that's been happening intermittently to me for a while.
If you want to be absolutely sure, you can establish the maximum MTU size manually using ping. Here's an explanation of how it's done. (Nutshell: ping -f -l mtusize address, where mtusize is the size in bytes of the packets you want to send.)
I have no idea why this only seems to affect MetaFilter, but if it bothers anything else I never noticed.
posted by Kadin2048 at 1:23 PM on January 3, 2008
If you want to be absolutely sure, you can establish the maximum MTU size manually using ping. Here's an explanation of how it's done. (Nutshell: ping -f -l mtusize address, where mtusize is the size in bytes of the packets you want to send.)
I have no idea why this only seems to affect MetaFilter, but if it bothers anything else I never noticed.
posted by Kadin2048 at 1:23 PM on January 3, 2008
Kadin2048, I'm glad to have some support for the MTU size theory. On a really minor note, I think for AmbroseChapel's Mac OS X 10.4 machine the command corresponding to "ping -f -l mtusize address" is "ping -D -s packetsize address".
posted by RichardP at 1:59 PM on January 3, 2008
posted by RichardP at 1:59 PM on January 3, 2008
Thanks again everyone. I'll try those things when I get home.
posted by AmbroseChapel at 2:34 PM on January 3, 2008
posted by AmbroseChapel at 2:34 PM on January 3, 2008
AmbroseChapel, I have an Exetel connection too, and had MTU problems last year. It first broke some time in April. As far as I know, it might have been broken ever since; I've never removed the firewall rule that I added to work around it.
posted by narge at 6:13 PM on January 3, 2008
posted by narge at 6:13 PM on January 3, 2008
Oops; yes, RichardP, you're right about the flags. It's definitely -D -s, not -f -l.
posted by Kadin2048 at 11:25 PM on January 3, 2008
posted by Kadin2048 at 11:25 PM on January 3, 2008
OK, doing the ping as suggested gives the following results:
1480 and above:
1470:
1460:
i.e. a normal-looking ping, in my limited experience.
posted by AmbroseChapel at 3:43 AM on January 4, 2008
1480 and above:
ping: sendto: Message too long1470:
PING metafilter.com (74.53.68.130): 1470 data bytes
556 bytes from mygateway1.ar7 (192.168.1.1): frag needed and DF set (MTU 1492)
Vr HL TOS Len ID Flg off TTL Pro cks Src Dst
4 5 00 05da ea82 2 0000 3f 01 fb3e 192.168.1.2 74.53.68.130
1460:
1468 bytes from 74.53.68.130: icmp_seq=0 ttl=110 time=240.674 msi.e. a normal-looking ping, in my limited experience.
posted by AmbroseChapel at 3:43 AM on January 4, 2008
...having said that, however, changing the MTU size in both the computer and the router still hasn't helped. Same old same old. It just constantly says it's waiting for the server.
posted by AmbroseChapel at 3:59 AM on January 4, 2008
posted by AmbroseChapel at 3:59 AM on January 4, 2008
Okay, I just tried removing that firewall rule (which reduces the TCP MSS to 1400 bytes for connections to 74.53.68.130, Metafilter's IP), and it's definitely still broken. I get the same symptoms; connections just hang forever.
It's odd that large pings work, though; they didn't before.
posted by narge at 6:09 AM on January 4, 2008
It's odd that large pings work, though; they didn't before.
posted by narge at 6:09 AM on January 4, 2008
I've now rebooted both the computer and the router, and it works.
Thanks everyone who helped.
posted by AmbroseChapel at 1:49 PM on January 4, 2008
Thanks everyone who helped.
posted by AmbroseChapel at 1:49 PM on January 4, 2008
You are not logged in, either login or create an account to post comments
posted by mathowie (staff) at 5:03 PM on January 2, 2008