Skip

why do these sites never load?
January 7, 2014 7:02 AM   Subscribe

Some sites never load on my ubuntu laptop. e.g. meetup.com, arxiv.org. why?!

These sites load on my mac, but not my ubuntu laptop. I've got a lenovo ultrabook yogi, and these sites wouldn't load when I was running raring ringtail or now when I'm running saucy. They don't load when I try them in firefox, chrome, or lynx. Please give me advice on troubleshooting this.
curl just sits there

curl -v http://arxiv.org/abs/1312.5670
* Adding handle: conn: 0x20a9e00
* Adding handle: send: 0
* Adding handle: recv: 0
* Curl_addHandleToPipeline: length: 1
* - Conn 0 (0x20a9e00) send_pipe: 1, recv_pipe: 0
* About to connect() to arxiv.org port 80 (#0)
* Trying 128.84.21.199...
posted by bleary to Technology (14 answers total) 1 user marked this as a favorite
 
What do you get for traceroute 128.84.21.199 on the two systems?

I get
$ traceroute 128.84.21.199
traceroute to 128.84.21.199 (128.84.21.199), 30 hops max, 40 byte packets
[lines 1-9 deleted]
10  vlan-62.newy.layer2.nlr.net (216.24.186.67)  78.358 ms  78.560 ms  78.515 ms
11  nyc1-6500-vl4040.net.cornell.edu (192.35.82.130)  77.969 ms  78.367 ms  78.090 ms
12  core2-6500-vl12.net.cornell.edu (132.236.222.13)  86.421 ms  86.177 ms  86.439 ms
13  sf1-6500-te5-4.net.cornell.edu (132.236.222.174)  88.134 ms  88.346 ms  86.472 ms
14  * * *
15  * * *
16  * * *
17  * * *
18  * * *
19  * * *
20  * * *
21  * * *
22  * * *
23  * * *
24  * * *
25  * * *
26  * * *
27  * * *
28  * * *
29  * * *
30  * * *
posted by grouse at 7:12 AM on January 7


Possible DNS issue? I don't know much about Linux, but on Windows/Mac I'd say to flush the DNS first, and if that doesn't work to try changing your DNS servers. This link might help.
posted by bluecore at 7:56 AM on January 7


For ubuntu I get
$ traceroute 128.84.21.199
traceroute to 128.84.21.199 (128.84.21.199), 30 hops max, 60 byte packets
[...]

10  te7-2.ccr01.buf02.atlas.cogentco.com (154.54.44.81)  82.348 ms
      te8-2.ccr01.buf02.atlas.cogentco.com (154.54.31.238)  77.146 ms  77.998 ms
11  te3-2.ccr01.syr01.atlas.cogentco.com (154.54.46.114)  87.071 ms  86.867 ms  79.143 ms
12  38.122.120.22 (38.122.120.22)  86.205 ms  85.161 ms  100.277 ms
13  core-6500-te4-7.net.cornell.edu (128.253.222.9)  87.249 ms  85.883 ms  87.157 ms
14  sf1-6500-te1-1.net.cornell.edu (128.253.222.174)  87.177 ms  87.109 ms  87.089 ms
15  * * *

[...]
For the mac I get
$ traceroute 128.84.21.199
traceroute to 128.84.21.199 (128.84.21.199), 64 hops max, 52 byte packets
[...]

10  te7-2.ccr01.buf02.atlas.cogentco.com (154.54.44.81)  81.153 ms
    te4-1.ccr01.buf02.atlas.cogentco.com (154.54.27.85)  282.579 ms
    te3-2.ccr01.buf02.atlas.cogentco.com (154.54.43.118)  173.399 ms
11  te3-2.ccr01.syr01.atlas.cogentco.com (154.54.46.114)  78.110 ms  87.786 ms  79.851 ms
12  38.122.120.22 (38.122.120.22)  86.977 ms  83.498 ms  84.457 ms
13  core-6500-te4-7.net.cornell.edu (128.253.222.9)  81.709 ms  81.138 ms  80.558 ms
14  sf1-6500-te1-1.net.cornell.edu (128.253.222.174)  127.148 ms  160.282 ms  83.104 ms
15  * * *

[...]

posted by bleary at 8:06 AM on January 7


also, maybe I should live boot some other distro... no time to do that immediately, but if it is a good idea I can try later tonight. (no cd, I would need to arrange another way)
posted by bleary at 8:08 AM on January 7 [1 favorite]


I just tried hitting the Arxiv URL with curl from a Linux machine at my house, and it worked fine. It's admittedly not a Ubuntu machine though. (It's Scientific Linux and old.) But this is not a general incompatibility with Linux, just to put some bounds around the problem.

It's also not a DNS issue based on the output above; you're resolving the IP correctly.

Complete WAG: It might be some sort of weird TCP windowing issue. I have had problems, particularly with certain versions of Ubuntu, where they enable crazy TCP settings based on somebody's idea of best practice, that don't play very well with old / misconfigured / shitty routers in various places on the Internet.

If you run sysctl -w "net.ipv4.tcp_window_scaling=0" as root (which will temporarily disable TCP scaling, until the next reboot), does that change anything?
posted by Kadin2048 at 8:26 AM on January 7


Kadin2048: " [...] If you run sysctl -w "net.ipv4.tcp_window_scaling=0" as root (which will temporarily disable TCP scaling, until the next reboot), does that change anything?"

No, still not loading. :(

I'll try more troubleshooting more later today.
posted by bleary at 8:59 AM on January 7


What if you try one of the arxiv mirrors? I think they are all exact mirrors but I'm not sure. This is the current list arxiv is giving:

cn.arXiv.org (China)
fr.arXiv.org (France)
de.arXiv.org (Germany)
in.arXiv.org (India)
jp.arXiv.org (Japan)
es.arXiv.org (Spain)
uk.arXiv.org (U.K.)
lanl.arXiv.org (née xxx.lanl.gov, U.S. mirror at Los Alamos)
posted by nat at 9:48 AM on January 7


Does this happen on multiple networks? I've seen some very confusing behaviour like that in the past when the network connection's MTU (maximum transmission unit) was lower than the system thought: small requests like DNS, which fit entirely within the real MTU, would work but as soon as something started to require a full packet it would silently be dropped – i.e. you could SSH in successfully and then the session would hang as soon as you typed a command like ls -l which displayed more than a few hundred bytes.

Fortunately, this is easier to test than it used to be. Also note the switch to use TCP to avoid any confusion caused by firewalls filtering on protocols other than the one you care about:

sudo traceroute -T --port=80 --mtu www.arXiv.org

This will attempt to do discovery automatically. If that doesn't work, you could try manually setting the packet length to something less than 1500 – some odd DSL / VPN lines used to be around 1400-1450 so try going much lower and see if it magically starts working:

sudo traceroute -T --port=80 --mtu www.arXiv.org 1200

One other tool which can be quite handy is LFT, which has a firewall discovery engine which might help if something along the way is filtering packets:

sudo lft -NET www.arxiv.org:80
posted by adamsc at 4:06 PM on January 7


adamsc: "Does this happen on multiple networks?

It does, unfortunately.

[interesting]
Fortunately, this is easier to test than it used to be. Also note the switch to use TCP to avoid any confusion caused by firewalls filtering on protocols other than the one you care about:

sudo traceroute -T --port=80 --mtu www.arXiv.org



I did this. I'm not sure what successful output should look like.
$ sudo traceroute -T --port=80 --mtu www.arXiv.org

traceroute to www.arXiv.org (128.84.21.199), 30 hops max, 56 byte packets
[...]
 8  be2003.ccr22.ord01.atlas.cogentco.com (154.54.29.21)  54.606 ms
    be2006.mpd21.ord01.atlas.cogentco.com (154.54.5.17)  54.069 ms  55.223 ms
 9  be2351.ccr21.cle04.atlas.cogentco.com (154.54.44.86)  64.028 ms *
    be2354.ccr21.cle04.atlas.cogentco.com (154.54.44.130)  63.481 ms
10  * * *
11  * * *
12  38.122.120.22 (38.122.120.22)  85.613 ms  84.884 ms  86.144 ms
13  core-6500-te4-7.net.cornell.edu (128.253.222.9)  86.954 ms  85.139 ms *
14  sf1-6500-te1-1.net.cornell.edu (128.253.222.174)  85.387 ms  85.254 ms  83.910 ms
15  * * *
[full of stars]
30  * * *
and with the length arg
$ sudo traceroute -T --port=80 --mtu www.arXiv.org 1200
traceroute to www.arXiv.org (128.84.21.199), 30 hops max, 56 byte packets
[...]
 8  be2004.mpd22.ord01.atlas.cogentco.com (154.54.5.9)  53.464 ms 54.813 ms
    be2006.mpd21.ord01.atlas.cogentco.com (154.54.5.17)  51.703 ms
 9  be2354.ccr21.cle04.atlas.cogentco.com (154.54.44.130)  61.934 ms  61.012 ms
    be2352.ccr21.cle04.atlas.cogentco.com (154.54.44.90)  64.395 ms
10  * * *
11  * * *
12  38.122.120.22 (38.122.120.22)  349.788 ms  86.244 ms  85.202 ms
13  core-6500-te4-7.net.cornell.edu (128.253.222.9)  100.088 ms  89.411 ms  84.866 ms
14  sf1-6500-te1-1.net.cornell.edu (128.253.222.174)  86.057 ms  85.643 ms  89.104 ms
15  * * *
btw, this happens for some other sites as well, but arXiv is a painful. Meetup is annoying too, because I'm an admin for a group, and I have to switch to my mac anytime I want to reply to someone.
posted by bleary at 6:01 PM on January 7


nat: "fr.arXiv.org"

works! what the heck. I hope this provides more information to someone helping.

I tried the first few. Here's traceroute for fr.
$ sudo traceroute -T --port=80 --mtu fr.arXiv.org 1200
traceroute to fr.arXiv.org (193.48.96.15), 30 hops max, 56 byte packets
[...]
 5  he-3-14-0-0-cr01.350ecermak.il.ibone.comcast.net (68.86.94.125)  26.510 ms  13.754 ms  11.686 ms
 6  he-4-2-0-0-cr01.newyork.ny.ibone.comcast.net (68.86.88.137)  30.620 ms  29.816 ms  31.975 ms
 7  * * *
 8  as1273.111eighthave.ny.ibone.comcast.net (173.167.56.150)  46.105 ms  33.632 ms  30.902 ms
 9  ae9-xcr1.bkl.cw.net (195.2.25.21)  104.489 ms  117.254 ms  104.165 ms
10  195.2.9.194 (195.2.9.194)  129.787 ms  113.171 ms  112.801 ms
11  giprenater-gw.par.cw.net (195.10.54.66)  168.680 ms  114.212 ms  114.838 ms
12  * * *
13  in2p3-lyon-vl3114-paris1-rtr-021.noc.renater.fr (193.51.186.177)  125.137 ms  141.247 ms  123.257 ms
14  ccsd10.in2p3.fr (193.48.96.15)  124.959 ms  125.507 ms  127.939 ms

posted by bleary at 6:05 PM on January 7


btw, someone asked me if
telnet arxiv.org 80
would work with the expectation that it would not, and I've verified that it does not though as you'd expect, telnetting to fr.arxiv.org 80 does.
posted by bleary at 9:54 AM on January 17


I'm running pretty thin on suggestions at this point (although you might want to consider asking this question on one of the Stack Overflow sites, like SuperUser or maybe ServerFault or NetworkEngineering).

My guess is that there's some router located between you and arxiv.org at Cornell, but not between you and fr.arxiv.org in France, that's causing the problem. But it looks like you got a good traceroute (at least to the border of Cornell's network where they must be blocking pings) with an MTU of 1200... so it's probably not an MTU problem. That's unfortunate because it'd be an easy fix.

You could test the transit-problem theory by pulling up other sites from similar locations to the broken ones and see if they're broken as well. E.g., do other sites at Cornell also fail? At least for me, the route to www.cornell.edu terminates at the same 128.253.222.174 node that the path to arxiv.org does. So you would expect it to be broken as well. Is it?
posted by Kadin2048 at 10:58 AM on January 17


Another datapoint, and I feel like an idiot for not noticing this before until someone at my hackerspace asked the question --meetup.com and arxiv.org are accessible from my linux laptop on the network at my hackerspace (and I haven't tried at the other places I work yet -- there are a couple of coffee shops I squat at sometimes). (reminder: my mac reaches the sites at home, but my linux laptop does not.)

I think you are right, Kadin2048, and I may need to post on one of the stack overflow sites.
posted by bleary at 7:26 AM on January 22


I'm in a bar with wifi, and can git arxiv and other sites. Here's the traceroute from here. I took out some of the hops because I'm not sure how private that info should be.
$ sudo traceroute -T --port=80 --mtu www.arXiv.org
traceroute to www.arXiv.org (128.84.21.199), 30 hops max, 60 byte packets


 3  * * *

 5  cgcil02jt.ip.att.net (12.122.81.17)  22.946 ms  21.889 ms  22.741 ms
 6  be2000.ccr21.ord03.atlas.cogentco.com (154.54.12.85)  81.589 ms  61.966 ms  62.441 ms
 7  be2003.ccr22.ord01.atlas.cogentco.com (154.54.29.21)  60.283 ms
    be2006.mpd21.ord01.atlas.cogentco.com (154.54.5.17)  64.822 ms  64.651 ms
 8  be2351.ccr21.cle04.atlas.cogentco.com (154.54.44.86)  71.447 ms
    be2353.ccr21.cle04.atlas.cogentco.com (154.54.44.98)  72.429 ms
    be2354.ccr21.cle04.atlas.cogentco.com (154.54.44.130)  66.128 ms
 9  * * *
10  * * *
11  38.122.120.22 (38.122.120.22)  60.191 ms  63.316 ms  67.134 ms
12  core-6500-te4-7.net.cornell.edu (128.253.222.9)  68.852 ms  73.645 ms  56.780 ms
13  sf1-6500-te1-1.net.cornell.edu (128.253.222.174)  58.456 ms  68.142 ms  61.088 ms
14  arxiv-web.arxiv.org (128.84.21.199)  60.342 ms  62.277 ms  60.345 ms

posted by bleary at 3:02 PM on January 26


« Older I just finished re-reading the...   |  Last night I stopped by my loc... Newer »

You are not logged in, either login or create an account to post comments



Post