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...
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...
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, 2014
posted by bluecore at 7:56 AM on January 7, 2014
Response by poster: For ubuntu I get
posted by bleary at 8:06 AM on January 7, 2014
$ 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, 2014
Response by poster: 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, 2014 [1 favorite]
posted by bleary at 8:08 AM on January 7, 2014 [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, 2014
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, 2014
Response by poster: 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, 2014
No, still not loading. :(
I'll try more troubleshooting more later today.
posted by bleary at 8:59 AM on January 7, 2014
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, 2014
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, 2014
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
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:
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:
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:
posted by adamsc at 4:06 PM on January 7, 2014
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.orgThis 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 1200One 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:80posted by adamsc at 4:06 PM on January 7, 2014
Response by poster: 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:
I did this. I'm not sure what successful output should look like.
posted by bleary at 6:01 PM on January 7, 2014
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.orgI 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, 2014
Response by poster: 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.
posted by bleary at 6:05 PM on January 7, 2014
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, 2014
Response by poster: btw, someone asked me if
posted by bleary at 9:54 AM on January 17, 2014
telnet arxiv.org 80would 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, 2014
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, 2014
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, 2014
Response by poster: 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, 2014
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, 2014
Response by poster: 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.
posted by bleary at 3:02 PM on January 26, 2014
$ 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, 2014
« Older Tom Bombadil is an ancient god beyond Gandalf's... | I got holes in my shoes and I'm way overdue Newer »
This thread is closed to new comments.
I get posted by grouse at 7:12 AM on January 7, 2014