Since recent changes at SETI BOINC, I and many others have been unable to connect to the servers without using proxy servers. The trouble is, each time someone posts details of a proxy server that works, it is either overloaded or disabled so it no longer works.

Can anyone post details of any proxy servers that are open and operating that will allow us all to access SETI??

True, it's impossible to contact server with GPRS, 56K and difficult with ISDN 64K without use any proxy. Can someone write a list of good proxy? Thanks.

---

GHz
BOINC.Italy

Hi.
There's some on this page.

http://www.iantighe.com/boincers.htm

Regards

Ian

Since recent changes at SETI BOINC, I and many others have been unable to connect to the servers without using proxy servers. The trouble is, each time someone posts details of a proxy server that works, it is either overloaded or disabled so it no longer works.

Can anyone post details of any proxy servers that are open and operating that will allow us all to access SETI??

If it's true that a proxy server fixes this, then it could very well be a routing problem.

If that's true, some traceroutes might be useful. You can post them here.

---

For routing problems, try dumping the DNS cache in all hardware in the chain that you have control of (ipconfig /flushdns for Windows systems, power cycle for most router appliances).

---

BOINC WIKI

For routing problems, try dumping the DNS cache in all hardware in the chain that you have control of (ipconfig /flushdns for Windows systems, power cycle for most router appliances).

If this is really a routing problem, we need to look at routing.

If it is a DNS problem, then the traceroute might show that too, but first thing first is: what machine(s) are they having trouble reaching, and how close do they get before things go astray.

---

Ned.....My gut feel on this is timing. There is another similar issue in thread "getting 500 response from server" . This is mostly Australia that is affected ...with some others.

http://setiathome.berkeley.edu/forum_thread.php?id=18705

Sometimes they can connect sometimes not. When not they use a proxy and all is OK for a while then not. So they move proxy and hey ho its OK for a while. I am hoping someone will send a packet trace without proxy. I would like to see server responses and web server responses.

Are any of you dial up users?

---

Here is an URL with some multi-country choices:
"http://publicproxyservers.com/page1.html"

Ned.....My gut feel on this is timing. There is another similar issue in thread "getting 500 response from server" . This is mostly Australia that is affected ...with some others.

http://setiathome.berkeley.edu/forum_thread.php?id=18705

Sometimes they can connect sometimes not. When not they use a proxy and all is OK for a while then not. So they move proxy and hey ho its OK for a while. I am hoping someone will send a packet trace without proxy. I would like to see server responses and web server responses.

Are any of you dial up users?

I have tried most of the previous suggestions. The only thing that is working for me at the moment is one of the proxy servers listed on Tigher's website (thanks for that!).

I have done route traces to several of the setiboinc servers - here is an example, with the first two hops (my local network) deleted:
3 745 ms 755 ms 727 ms atm1-0-1.lon54.melbourne.telstra.net [139.130.4.149]
4 821 ms 715 ms 735 ms 10gigabitethernet9-0.win-core1.melbourne.telstra.net [203.50.79.129]
5 744 ms 699 ms 719 ms pos9-0.ken-core4.sydney.telstra.net [203.50.6.17]
6 734 ms 719 ms 735 ms 10gigabitethernet3-0.pad-core4.sydney.telstra.net [203.50.6.86]
7 705 ms 779 ms 767 ms 10gigabitethernet2-2.syd-core01.sydney.net.reach.com [203.50.13.38]
8 872 ms 860 ms 859 ms i-12-3.wil-core02.net.reach.com [202.84.249.205]
9 904 ms 984 ms 919 ms i-6-2.wil04.net.reach.com [202.84.251.186]
10 * * * Request timed out.
11 922 ms 983 ms 963 ms dc-slo-dc2--lax-dc1-pos.cenic.net [137.164.22.25]
12 956 ms 987 ms 900 ms dc-slo-dc1--dc2-df-iconn-1.cenic.net [137.164.22.122]
13 913 ms 863 ms 855 ms dc-sol-dc2--slo-dc1-pos.cenic.net [137.164.22.27]
14 886 ms 887 ms 887 ms dc-sol-dc1--sol-dc2-df-iconn-2.cenic.net [137.164.22.212]
15 898 ms 923 ms 859 ms dc-svl-dc1--sol-dc1-pos.cenic.net [137.164.22.29]
16 842 ms 860 ms 859 ms dc-svl-dc1--svl-dc2-df-iconn-2.cenic.net [137.164.22.208]
17 890 ms 827 ms 923 ms ucb--svl-dc1-egm.cenic.net [137.164.23.66]
18 935 ms 972 ms 887 ms g3-17.inr-202-reccev.berkeley.edu [128.32.0.35]
19 901 ms 888 ms 859 ms g6-2.inr-230-spr.berkeley.edu [128.32.255.114]
20 933 ms * 860 ms solen.ssl.berkeley.edu [128.32.18.209]
21 * * 1193 ms galileo.ssl.berkeley.edu [128.32.18.173]

Obviously there are some problems, but I am not convinced that this is the issue. I suspect that most of those having trouble in Australia are using the same ISP, and it probably does not matter what type of connection it is - mine is a satellite.

I am not experiencing any of the 500 errors that others have been reporting. My problem is simply that without the proxy servers, the messages in the Boinc Manager are all of this type:

18/08/2005 8:57:58 PM|SETI@home|Scheduler RPC to http://setiboinc.ssl.berkeley.edu/sah_cgi/cgi failed
18/08/2005 8:57:58 PM|SETI@home|No schedulers responded
18/08/2005 8:57:58 PM|SETI@home|Deferring communication with project for 1 minutes and 0 seconds
When I turn on the proxy server and send the same request a few seconds later, it is successful (eg 18/08/2005 8:58:59 PM|SETI@home|Scheduler RPC to http://setiboinc.ssl.berkeley.edu/sah_cgi/cgi succeeded)

I am no expert in these matters, and am happy to be guided by those that are.

---

I have done route traces to several of the setiboinc servers - here is an example, with the first two hops (my local network) deleted:

20 933 ms * 860 ms solen.ssl.berkeley.edu [128.32.18.209]
21 * * 1193 ms galileo.ssl.berkeley.edu [128.32.18.173]

I'd be interested in pings at this point. The last hop shows two dropped packets and one really slow -- but 1.2 seconds isn't fatal. We need 20 or 30 pings to know more....

Obviously there are some problems, but I am not convinced that this is the issue. I suspect that most of those having trouble in Australia are using the same ISP, and it probably does not matter what type of connection it is - mine is a satellite.

The speed of light is inconveniently slow, and that could very well be a big part of the problem. Most Satellite ISPs play fast-and-loose with TCP (and force you through their proxies) to make up for the long latency.

We'd also like to know more about setiboincdata.ssl.berkeley.edu, since that is on a different backbone.

---

Ned.....My gut feel on this is timing. There is another similar issue in thread "getting 500 response from server" . This is mostly Australia that is affected ...with some others.

http://setiathome.berkeley.edu/forum_thread.php?id=18705

Sometimes they can connect sometimes not. When not they use a proxy and all is OK for a while then not. So they move proxy and hey ho its OK for a while. I am hoping someone will send a packet trace without proxy. I would like to see server responses and web server responses.

Are any of you dial up users?

Big hint in a post after yours, Ian: satellite feeds.

That adds about a second of latency, and the usual TCP settings expect a terrestrial connection no more than about half-way 'round the planet.

There are also collisions and "hidden terminal" problems. Most Satellite ISPs do some pretty interesting things to make this less of a problem, but it really can hose up something like what SETI does.

---

Ned.....My gut feel on this is timing. There is another similar issue in thread "getting 500 response from server" . This is mostly Australia that is affected ...with some others.

http://setiathome.berkeley.edu/forum_thread.php?id=18705

Sometimes they can connect sometimes not. When not they use a proxy and all is OK for a while then not. So they move proxy and hey ho its OK for a while. I am hoping someone will send a packet trace without proxy. I would like to see server responses and web server responses.

Are any of you dial up users?

Big hint in a post after yours, Ian: satellite feeds.

That adds about a second of latency, and the usual TCP settings expect a terrestrial connection no more than about half-way 'round the planet.

There are also collisions and "hidden terminal" problems. Most Satellite ISPs do some pretty interesting things to make this less of a problem, but it really can hose up something like what SETI does.

Yes Ned....nice clue. I'm not sure things will ever be better for them with that order of "lag". Hmmmm. Proxy still seems best bet. We will have to think about what else can be done....but my guess is not a lot or try find some route that is more forgiving on timers.

---

Ned.....My gut feel on this is timing. There is another similar issue in thread "getting 500 response from server" . This is mostly Australia that is affected ...with some others.

http://setiathome.berkeley.edu/forum_thread.php?id=18705

Sometimes they can connect sometimes not. When not they use a proxy and all is OK for a while then not. So they move proxy and hey ho its OK for a while. I am hoping someone will send a packet trace without proxy. I would like to see server responses and web server responses.

Are any of you dial up users?

Big hint in a post after yours, Ian: satellite feeds.

That adds about a second of latency, and the usual TCP settings expect a terrestrial connection no more than about half-way 'round the planet.

There are also collisions and "hidden terminal" problems. Most Satellite ISPs do some pretty interesting things to make this less of a problem, but it really can hose up something like what SETI does.

Yes Ned....nice clue. I'm not sure things will ever be better for them with that order of "lag". Hmmmm. Proxy still seems best bet. We will have to think about what else can be done....but my guess is not a lot or try find some route that is more forgiving on timers.

I am also having the same problems. Proxy works ok for a while, them exhibits same problem. I have an ADSL connection, not dial up or satelite. And not in Australia.
Stephen

---

I am also having the same problems. Proxy works ok for a while, them exhibits same problem. I have an ADSL connection, not dial up or satelite. And not in Australia.
Stephen

The use of proxies is a good way to diagnose a connectivity problem, but it also means that you are getting along based on the generosity of others (the folks who own the proxy and provide that bandwidth). In some cases, the unintended generosity of others.

Shuffling among proxies is not the solution. The solution is to figure out why you needed a proxy in the first place.

... and "God is in the details."

First, we need to know if you get the right IP addresses for the right servers (that we aren't fighting a DNS problem) then we need to look at the path from you to each of the servers at Berkeley.

Then we can work on it from there.

---

Hope this tracert is useful:
Microsoft Windows XP [Version 5.1.2600]
(C) Copyright 1985-2001 Microsoft Corp.

C:\Documents and Settings\Stephen Taylor>tracert setiboinc.ssl.berkeley.edu

Tracing route to galileo.ssl.berkeley.edu [128.32.18.173]
over a maximum of 30 hops:

1 24 ms 2 ms * mygateway [10.1.1.1]
2 63 ms 43 ms 44 ms 222-152-172-1.jetstream.xtra.co.nz [222.152.172.1]
3 59 ms 42 ms * 210.55.205.249
4 76 ms 58 ms 62 ms fid-int.tkbr4.global-gateway.net.nz [202.50.245.198]
5 74 ms 60 ms 58 ms vlan-283.tkbr4.global-gateway.net.nz [202.50.245.197]
6 71 ms 58 ms 57 ms pc1-30.tkbr3.global-gateway.net.nz [210.55.202.65]
7 217 ms 205 ms 198 ms so1-1-3-0.labr3.global-gateway.net.nz [202.37.245.61]
8 199 ms 199 ms 199 ms so2-0-0-0.labr4.global-gateway.net.nz [203.96.120.102]
9 201 ms * 200 ms g11-2-107.core01.lax05.atlas.cogentco.com [154.54.11.145]
10 197 ms 200 ms 199 ms p9-2.core01.lax01.atlas.cogentco.com [154.54.1.33]
11 201 ms 221 ms 209 ms p14-0.core01.sjc01.atlas.cogentco.com [66.28.4.74]
12 209 ms 212 ms 207 ms p4-0.core01.sfo01.atlas.cogentco.com [66.28.4.93]
13 207 ms 209 ms 209 ms p15-0.core02.sfo01.atlas.cogentco.com [66.28.4.70]
14 207 ms 210 ms 209 ms CENIC.demarc.cogentco.com [38.112.6.226]
15 205 ms 209 ms 211 ms dc-svl-isp--oak-isp-t2.cenic.net [137.164.40.215]
16 205 ms 209 ms 210 ms inet-ucb--svl-isp.cenic.net [137.164.24.106]
17 213 ms 210 ms 209 ms vlan193.inr-201-eva.Berkeley.EDU [128.32.0.74]
18 210 ms 209 ms 210 ms g6-1.inr-230-spr.Berkeley.EDU [128.32.255.110]
19 210 ms 209 ms 209 ms solen.SSL.Berkeley.EDU [128.32.18.209]
20 208 ms 209 ms 209 ms galileo.SSL.Berkeley.EDU [128.32.18.173]

Trace complete.

/Stephen

---

Hope this tracert is useful:
Microsoft Windows XP [Version 5.1.2600]
(C) Copyright 1985-2001 Microsoft Corp.

C:Documents and SettingsStephen Taylor>tracert setiboinc.ssl.berkeley.edu

Tracing route to galileo.ssl.berkeley.edu [128.32.18.173]
over a maximum of 30 hops:

{snip}

16 205 ms 209 ms 210 ms inet-ucb--svl-isp.cenic.net [137.164.24.106]
17 213 ms 210 ms 209 ms vlan193.inr-201-eva.Berkeley.EDU [128.32.0.74]
18 210 ms 209 ms 210 ms g6-1.inr-230-spr.Berkeley.EDU [128.32.255.110]
19 210 ms 209 ms 209 ms solen.SSL.Berkeley.EDU [128.32.18.209]
20 208 ms 209 ms 209 ms galileo.SSL.Berkeley.EDU [128.32.18.173]

Trace complete.

/Stephen

Yes, it is. Now, are you having trouble uploading or trouble reporting?

If you are having trouble with uploads/downloads, we need a trace to setiboincdata.ssl.berkeley.edu instead.

Sorry.

---

Yes, it is. Now, are you having trouble uploading or trouble reporting?

If you are having trouble with uploads/downloads, we need a trace to setiboincdata.ssl.berkeley.edu instead.

Sorry.

Ok (I am a bit new at this). Problems with both uploads/downloads & reporting, but the uploads/downloads seem more of an issue - hope that makes sense. Here is another tracert as requested.

tracert setiboincdata.ssl.berkeley.edu

Tracing route to setiboincdata.ssl.berkeley.edu [66.28.250.125]
over a maximum of 30 hops:

>>
12 200 ms 209 ms 209 ms p4-0.core01.sfo01.atlas.cogentco.com [66.28.4.93]
13 210 ms 210 ms 209 ms UC-Berkeley.demarc.cogentco.com [66.250.4.74]
14 209 ms 209 ms 209 ms setiboincdata.ssl.berkeley.edu [66.28.250.125]

Trace complete.

/Stephen

---

Ok (I am a bit new at this). Problems with both uploads/downloads & reporting, but the uploads/downloads seem more of an issue - hope that makes sense. Here is another tracert as requested.

tracert setiboincdata.ssl.berkeley.edu

Tracing route to setiboincdata.ssl.berkeley.edu [66.28.250.125]
over a maximum of 30 hops:

>>
12 200 ms 209 ms 209 ms p4-0.core01.sfo01.atlas.cogentco.com [66.28.4.93]
13 210 ms 210 ms 209 ms UC-Berkeley.demarc.cogentco.com [66.250.4.74]
14 209 ms 209 ms 209 ms setiboincdata.ssl.berkeley.edu [66.28.250.125]

Trace complete.

/Stephen

Don't worry, there is a fair amount of detail that there is just no easy way to get short of some serious study. Things like the scheduler and data servers actually being on different networks....

I actually like the routing, nothing between your provider and Cogent. 200 msec. isn't bad, and it's much better than the nearly 1200 msec that Wang Solutions is seeing. I don't see any missed packets on yours.

So my next thought is: what's running on your machine to try to protect it from the internet? Could we have an anti-virus/anti-spyware app. doing something awful?

---

Don't worry, there is a fair amount of detail that there is just no easy way to get short of some serious study. Things like the scheduler and data servers actually being on different networks....

I actually like the routing, nothing between your provider and Cogent. 200 msec. isn't bad, and it's much better than the nearly 1200 msec that Wang Solutions is seeing. I don't see any missed packets on yours.

So my next thought is: what's running on your machine to try to protect it from the internet? Could we have an anti-virus/anti-spyware app. doing something awful?

I currently have two machines setup on BOINC, but they and their setups are similar. Both run AVG anti-virus, and Microsoft Antispyware software. Plus both run standard Microsoft XP firewall software. Plus the ADSL modem/router has a built in firewall. I am relatively new to BOINC Seti (Used to run Seti classic on one machine), and didn't notice any problems until late July.
/Stephen

---

How did you install your version of Boinc on the machines, as a single/multi user install or as a service?
What did you press when the XP firewall asked you for allowing both boinc.exe and boincmgr.exe to try to reach the internet?

Is any other program using port 1043 on the firewall, either the XP one or the one in your router?

Also, can you give some examples of possible error messages you get in your messages tab in the GUI when you try to upload/download?

---