Message boards :
Number crunching :
Users from Germany reporting bad route
Message board moderation
Author | Message |
---|---|
jason_gee Send message Joined: 24 Nov 06 Posts: 7489 Credit: 91,093,184 RAC: 0 |
Several Lunatics users from Germany are reporting the issue of not being able to access the website(s) at Berkeley: Jason traceroute for setiathome.berkeley.edu: "Living by the wisdom of computer science doesn't sound so bad after all. And unlike most advice, it's backed up by proofs." -- Algorithms to live by: The computer science of human decisions. |
speedimic Send message Joined: 28 Sep 02 Posts: 362 Credit: 16,590,653 RAC: 0 |
here we go Germany Online via some slooooow US proxy. As stated at lunatics: DNS is not the problem. Tracerouting doesn't give us a clue either. It get's stuck at inr-230 from wherever I try (even the Cogent-router at Los Angeles), but from the US there is no problem to reach Seti. Inr-230 simply (seems) to block traces. Ping goes through. - HTTP doesn't. mic. |
1mp0£173 Send message Joined: 3 Apr 99 Posts: 8423 Credit: 356,897 RAC: 0 |
Several Lunatics users from Germany are reporting the issue of not being able to access the website(s) at Berkeley: You're assuming that every router at Berkeley returns pings. That isn't necessarily so. |
jason_gee Send message Joined: 24 Nov 06 Posts: 7489 Credit: 91,093,184 RAC: 0 |
You're assuming that every router at Berkeley returns pings. That isn't necessarily so. Nope, I'm assuming that the German users who can't reach the site in fact can't. The traceroute is provided by such a user, just in case it's of any help whatsoever. "Living by the wisdom of computer science doesn't sound so bad after all. And unlike most advice, it's backed up by proofs." -- Algorithms to live by: The computer science of human decisions. |
speedimic Send message Joined: 28 Sep 02 Posts: 362 Credit: 16,590,653 RAC: 0 |
You're assuming that every router at Berkeley returns pings. That isn't necessarily so. That's what I was trying to say. g3-19.inr-201-eva.berkeley.edu does - g6-1.inr-230-spr.berkeley.edu doesn't. Problem WAS: ICPM goes through. - HTTP doesn't. However, problem seems to be solved... mic. |
Richard Haselgrove Send message Joined: 4 Jul 99 Posts: 14650 Credit: 200,643,578 RAC: 874 |
Users in Germany are continuing to report HTTP problems this morning. And I have an intermittent download problem on one machine (only) - others on the same LAN are fine. Debug reports 09/10/2008 11:11:17||[file_xfer_debug] PERS_FILE_XFER::start_xfer(): URL: http://boinc2.ssl.berkeley.edu/sah/download_fanout/1dc/19au08aa.25729.25021.10.8.224 09/10/2008 11:11:18||[http_debug] [ID#23] info: About to connect() to boinc2.ssl.berkeley.edu port 80 (#0) 09/10/2008 11:11:18||[http_debug] [ID#23] info: Trying [b][color=red]208.68.240.13[/color][/b]... 09/10/2008 11:11:18||[http_debug] [ID#23] info: Connected to boinc2.ssl.berkeley.edu (208.68.240.13) port 80 (#0) 09/10/2008 11:11:18||[http_debug] [ID#23] Sent header to server: GET /sah/download_fanout/1dc/19au08aa.25729.25021.10.8.224 HTTP/1.1 User-Agent: BOINC client (windows_intelx86 5.10.13) Host: boinc2.ssl.berkeley.edu Accept: */* Accept-Encoding: deflate, gzip Content-Type: application/x-www-form-urlencoded 09/10/2008 11:11:18||[http_debug] [ID#23] Received header from server: [b][color=red]HTTP/1.0 503 Service Unavailable[/color][/b] 09/10/2008 11:11:18||[http_debug] [ID#23] Received header from server: Content-Type: text/html 09/10/2008 11:11:18||[http_debug] [ID#23] Received header from server: Content-Length: 53 09/10/2008 11:11:18||[http_xfer_debug] HTTP: wrote 53 bytes 09/10/2008 11:11:18||[http_debug] [ID#23] info: Closing connection #0 09/10/2008 11:11:18||[file_xfer_debug] FILE_XFER_SET::poll(): http op done; retval -184 09/10/2008 11:11:18||[file_xfer_debug] PERS_FILE_XFER::poll(): file transfer status -184 So it seems that at least one server is misconfigured - it is trying (and failing) to use HTTP/1.0, when the GET specifies HTTP/1.1 Server 208.68.240.18 uses HTTP/1.1 correctly. |
[B^S] madmac Send message Joined: 9 Feb 04 Posts: 1175 Credit: 4,754,897 RAC: 0 |
|
gomeyer Send message Joined: 21 May 99 Posts: 488 Credit: 50,370,425 RAC: 0 |
I’m also seeing this in SE Pennsylvania so the problem does not appear to be unique to overseas traffic. I’ve become used to slow comm with Berkeley during times of high network traffic (according to the Cricket Graphs) but in this case there is no such correlation. The problem appears as periods of constant HTTP errors on downloads only; UL’s and reporting are normal. Each download attempt errors immediately, not after a timeout. This started about the time of Tuesday’s normal outage or shortly afterward and has been seen on at least two machines. Eventually the DL’s do come down all at once. |
speedimic Send message Joined: 28 Sep 02 Posts: 362 Credit: 16,590,653 RAC: 0 |
ok, did some more testing... Richard's up/download problem has got nothing to do with our http problem. boinc2.ssl.berkeley.edu is in a completely different network (208.68.something... (Hurricane Electric ??)) and works setiathome.berkeley.edu is in 128.32.something... (Campus network) and doesn't work fragment1.berkeley.edu (the Cricket grapher) is in 128.32.something... (Campus network) and doesn't work that's why up/downloads work, but the website doesn't. Taking that "different ISP- Different status" thing into account, I'd say it's some kind of peering problem here in Germany (especially Telekom / DE-CIX). (my post at lunatics) Now THAT is really strange: It's ok on my Windows notebook (no proxy, any browser), but still stuck on my Linux-box (no proxy, Firefox) and back in Office (every OS/browser). All Telekom (ISP). mic. |
Richard Haselgrove Send message Joined: 4 Jul 99 Posts: 14650 Credit: 200,643,578 RAC: 874 |
ok, did some more testing... This is getting weirder. Just got this from BOINC debug: 09/10/2008 17:10:47|SETI@home|[file_xfer] Started download of file 18au08af.30717.24612.15.8.186 09/10/2008 17:10:48||[http_debug] [ID#4] info: About to connect() to boinc2.ssl.berkeley.edu port 80 (#0) 09/10/2008 17:10:48||[http_debug] [ID#4] info: Trying [color=red]13.240.68.208[/color]... 09/10/2008 17:11:09||[http_debug] [ID#4] info: Timed out 09/10/2008 17:11:09||[http_debug] [ID#4] info: Failed connect to boinc2.ssl.berkeley.edu:80; No error Where did 13.240.68.208 come from? That's not on any of the LANs we know about - and it's not responding to pings or name look-ups. Edit: During the same debug session, I happened to finish some work. Uploads worked: 09/10/2008 17:10:43||[http_debug] [ID#2] info: About to connect() to setiboincdata.ssl.berkeley.edu port 80 (#0) 09/10/2008 17:10:43||[http_debug] [ID#2] info: Trying 208.68.240.16... 09/10/2008 17:10:43||[http_debug] [ID#2] info: Connected to setiboincdata.ssl.berkeley.edu (208.68.240.16) port 80 (#0) and so did reporting: 09/10/2008 17:15:16||[http_debug] [ID#6] info: About to connect() to setiboinc.ssl.berkeley.edu port 80 (#0) 09/10/2008 17:15:16||[http_debug] [ID#6] info: Trying 208.68.240.20... 09/10/2008 17:15:16||[http_debug] [ID#6] info: Connected to setiboinc.ssl.berkeley.edu (208.68.240.20) port 80 (#0) |
Dr. C.E.T.I. Send message Joined: 29 Feb 00 Posts: 16019 Credit: 794,685 RAC: 0 |
. . . that IP (13.240.68.208) is steathed and the Domain is unknown anybody else know where it's comin' from? BOINC Wiki . . . Science Status Page . . . |
Dr. C.E.T.I. Send message Joined: 29 Feb 00 Posts: 16019 Credit: 794,685 RAC: 0 |
. . . if one checks the BOINC_Projects Forum:
> ;) i could be mistaken though . . . BOINC Wiki . . . Science Status Page . . . |
speedimic Send message Joined: 28 Sep 02 Posts: 362 Credit: 16,590,653 RAC: 0 |
Where did 13.240.68.208 come from? That's not on any of the LANs we know about - and it's not responding to pings or name look-ups. looks like the PTR... but then it should be something like 13.240.68.208.in-addr.arpa. boinc2.ssl.berkeley.edu resolves to 208.68.240.13 and 208.68.240.18 PTR 13.240.68.208.in-addr.arpa. and 18.240.68.208.in-addr.arpa. setiboinc.ssl.berkeley.edu resolves to 208.68.240.20 PTR 20.240.68.208.in-addr.arpa. setiboincdata.ssl.berkeley.edu resolves to 208.68.240.16 PTR 16.240.68.208.in-addr.arpa. edit: typos mic. |
speedimic Send message Joined: 28 Sep 02 Posts: 362 Credit: 16,590,653 RAC: 0 |
Now then to my windows - linux problem: Both in my home-LAN and using the same internet connection. Windows tracert: Routenverfolgung zu setiathome.SSL.berkeley.edu [128.32.18.150] über maximal 30 Abschnitte: 1 <1 ms <1 ms <1 ms eumex.ip [192.168.16.1] 2 43 ms 43 ms 43 ms 217.0.118.202 3 44 ms 44 ms 44 ms 87.186.251.22 4 138 ms 138 ms 137 ms 194.25.6.41 5 146 ms 142 ms 141 ms 62.156.128.110 6 139 ms 138 ms 145 ms sl-st20-ash-13-0-0.sprintlink.net [144.232.28.5] 7 143 ms 143 ms 143 ms dcp-brdr-02.inet.qwest.net [63.146.26.81] 8 * * 140 ms dcx-core-01.inet.qwest.net [205.171.251.33] 9 205 ms 217 ms 209 ms los-core-02.inet.qwest.net [67.14.22.18] 10 209 ms 208 ms 208 ms los-edge-01.inet.qwest.net [205.171.32.46] 11 242 ms 232 ms 203 ms 63.147.28.182 12 218 ms 217 ms 217 ms dc-svl-isp--lax-isp-t1.cenic.net [137.164.40.220] 13 219 ms 219 ms 219 ms inet-ucb--svl-isp.cenic.net [137.164.24.106] 14 215 ms 215 ms 214 ms g3-19.inr-201-eva.Berkeley.EDU [128.32.0.58] 15 220 ms 219 ms 219 ms g6-1.inr-230-spr.Berkeley.EDU [128.32.255.110] 16 * * * Zeitüberschreitung der Anforderung. 17 221 ms 218 ms 214 ms thinman.ssl.berkeley.edu [128.32.18.150] Linux traceroute: traceroute to setiathome.berkeley.edu (128.32.18.150), 30 hops max, 40 byte packets 1 eumex.ip (192.168.16.1) 0.698 ms 1.078 ms 1.071 ms 2 217.0.118.202 (217.0.118.202) 44.478 ms 47.535 ms 50.049 ms 3 87.186.251.22 (87.186.251.22) 53.484 ms 56.362 ms 59.293 ms 4 194.25.6.41 (194.25.6.41) 161.529 ms 161.559 ms 164.252 ms 5 62.156.128.110 (62.156.128.110) 165.497 ms 167.900 ms 170.842 ms 6 sl-st20-ash-5-0-0.sprintlink.net (144.232.3.76) 173.439 ms 165.408 ms 167.798 ms 7 dcp-brdr-02.inet.qwest.net (63.146.26.81) 175.550 ms 143.394 ms 143.571 ms 8 dcx-core-01.inet.qwest.net (205.171.251.33) 143.210 ms 151.847 ms 152.283 ms 9 los-core-01.inet.qwest.net (67.14.22.10) 215.051 ms 218.673 ms los-core-02.inet.qwest.net (67.14.22.18) 226.567 ms 10 los-edge-01.inet.qwest.net (205.171.32.46) 228.041 ms 230.866 ms 233.928 ms 11 63.147.28.182 (63.147.28.182) 238.338 ms 239.724 ms 242.207 ms 12 dc-svl-isp--lax-isp-t1.cenic.net (137.164.40.220) 249.416 ms 252.704 ms 255.111 ms 13 inet-ucb--svl-isp.cenic.net (137.164.24.106) 220.266 ms 220.054 ms 219.656 ms 14 g3-19.inr-201-eva.Berkeley.EDU (128.32.0.58) 218.089 ms 215.881 ms 216.618 ms 15 g6-1.inr-230-spr.Berkeley.EDU (128.32.255.110) 220.657 ms 220.261 ms 222.679 ms 16 * * * ... 30 * * * As you can see it's identical till I hit hop 9 - the los-core-01.inet.qwest.net or los-core-02.inet.qwest.net Both routes somehow take me to Berkeley (Inr-230), but only one to thinman. mic. |
tullio Send message Joined: 9 Apr 04 Posts: 8797 Credit: 2,930,782 RAC: 1 |
Could not connect to either SETI@home and boinc.berkeley.edu the whole day. Pings were returned, however. I am connecting from Italy. Tullio |
crazyrabbit1 Send message Joined: 17 Sep 06 Posts: 35 Credit: 2,282,319 RAC: 0 |
Have the same problem since yesterday, called my provcider and now it looks like its working again. Do not know how it is from Italy, but try it again. After closing all browsers and restart them i can connect to seti. |
Jord Send message Joined: 9 Jun 99 Posts: 15184 Credit: 4,362,181 RAC: 3 |
Checking it in Sam Spade, it's leased to Xerox Corporation. Is the new server a photocopier as well? ;-) |
speedimic Send message Joined: 28 Sep 02 Posts: 362 Credit: 16,590,653 RAC: 0 |
Now it works forme too. All OS all browsers. I'd sill like to know what the problem was... @Jord: It's the reverse pointer, not any Xerox IP. mic. |
crazyrabbit1 Send message Joined: 17 Sep 06 Posts: 35 Credit: 2,282,319 RAC: 0 |
just called t-online, and they said they had a problem with a dns-server and send every request to seti to nowhere. Let's hope that the problem is fixed right now. |
speedimic Send message Joined: 28 Sep 02 Posts: 362 Credit: 16,590,653 RAC: 0 |
just called t-online, and they said they had a problem with a dns-server and send every request to seti to nowhere. Let's hope that the problem is fixed right now. That's ridiculous! 1) the pings went cleanly through. That includes resolving setiathome.berkeley.edu to 128.32.18.150 2) I tried http://128.32.18.150 and got a timeout. No DNS-server involved in that. mic. |
©2024 University of California
SETI@home and Astropulse are funded by grants from the National Science Foundation, NASA, and donations from SETI@home volunteers. AstroPulse is funded in part by the NSF through grant AST-0307956.