Neither of my machines has been able to communicate in any way with the servers. Always gives me

Scheduler request to http://setiboinc.ssl.berkely.edi/sah_cgi/cgi failed with a return value of 500.

No schedulers responded.


Anyone know what the deal is here? It's frustrating.

Neither of my machines has been able to communicate in any way with the servers. Always gives me

Scheduler request to http://setiboinc.ssl.berkely.edi/sah_cgi/cgi failed with a return value of 500.

No schedulers responded.


Anyone know what the deal is here? It's frustrating.

Have a look at this and this thread - you're not alone, but you are part of a small minority with a real and frustrating problem, which people with far more technical knowledge than me are trying to solve.

I'm sure they would appreciate it if you could post again, with more details of your setup - how your machines link up to the internet, etc. - so they can help you sort it out.

Richard

Neither of my machines has been able to communicate in any way with the servers. Always gives me

Scheduler request to http://setiboinc.ssl.berkely.edi/sah_cgi/cgi failed with a return value of 500.

No schedulers responded.


Anyone know what the deal is here? It's frustrating.

Could we get about 10 lines before this one? There may be other information that we're missing.

Also, this says you're having trouble reporting work, not necessarily uploading, so we need to work the right problem.

---

I looked at your computer list and it looks like you now have one work units to work on. Maybe something happened to that work unit and SETI or the BOINC manager thinks that you still have enough work.

You may want to increase your cache a little if you are having trouble keeping enough work or so you don't need to watch so close. Or in your case so you have some.

Go to "YOUR ACCOUNTS" at the top of the page. Click on the blue "View or edit general preferences". At the bottom of the page click on the "Edit preferences". That will allow you to increase the spot that says "Connect to network about every". That will increase the amount of work that you will have on your machine ready to run. Maybe try one day or something small at first. You want it small enough that you get the work returned on time but big enough to get through an outage.

To make the change show up immediately, go to the "Projects" tab in the BOINC manager and click to highlight the SETI project. Then push the "Update" button. You can also just wait until the next time it connects on its own.

Of course with the "500" error I could be way off base here. I guess I just sort of panic when I see only one work unit ready to run.

---

If you are using a SOCKS PROXY or are going through a PROXY Server See.

I'm also not getting any work. I've had one unit since Dec 12.
Messages:
1/15/2006 7:26:45 AM|SETI@home|Scheduler request to http://setiboinc.ssl.berkeley.edu/sah_cgi/cgi succeeded
1/15/2006 7:26:45 AM|SETI@home|No start tag in scheduler reply
1/15/2006 7:26:45 AM|SETI@home|Can't parse scheduler reply
1/15/2006 7:27:45 AM|SETI@home|Sending scheduler request to http://setiboinc.ssl.berkeley.edu/sah_cgi/cgi
1/15/2006 7:27:45 AM|SETI@home|Reason: Requested by user
1/15/2006 7:27:45 AM|SETI@home|Requesting 8640 seconds of new work
1/15/2006 7:28:00 AM|SETI@home|Scheduler request to http://setiboinc.ssl.berkeley.edu/sah_cgi/cgi succeeded
1/15/2006 7:28:00 AM|SETI@home|No start tag in scheduler reply
1/15/2006 7:28:00 AM|SETI@home|Can't parse scheduler reply
1/15/2006 7:29:30 AM|SETI@home|Sending scheduler request to http://setiboinc.ssl.berkeley.edu/sah_cgi/cgi
1/15/2006 7:29:30 AM|SETI@home|Reason: Requested by user
1/15/2006 7:29:30 AM|SETI@home|Requesting 8640 seconds of new work
1/15/2006 7:29:45 AM|SETI@home|Scheduler request to http://setiboinc.ssl.berkeley.edu/sah_cgi/cgi succeeded

Terry Pettle

---

1/15/2006 7:26:45 AM|SETI@home|No start tag in scheduler reply

This is a strange one... and one of the _few_ cases where I think a "reset" is in order, or possibly even detaching and reattaching to the project. (Assuming this is the same error you've been getting for a month.)

1/15/2006 7:26:45 AM|SETI@home|No start tag in scheduler reply

This is a strange one... and one of the _few_ cases where I think a "reset" is in order, or possibly even detaching and reattaching to the project. (Assuming this is the same error you've been getting for a month.)

I you're going to go that far then you might as well reload the client in case of any file corruption.

---

Account frozen...

1/15/2006 7:28:00 AM|SETI@home|No start tag in scheduler reply
1/15/2006 7:28:00 AM|SETI@home|Can't parse scheduler reply

This certainly looks like a communications error -- that what you're getting back is missing at least some of what the scheduler sent.

I'd be interested in how you connect to the internet, and if cable/dsl, a little suspicious of your router.

---

dsl... I had 4 WU trying to up load from Dec 12 to Dec 31. They uploaded and
I recieved 1 WU it was ready in 5 hrs or so then took a week to upload... no
downloads since. I have reset several times,suspended,restarted,re-installed
5.1.13 twice


1/15/2006 10:48:21 AM|SETI@home|Scheduler request to http://setiboinc.ssl.berkeley.edu/sah_cgi/cgi failed with a return value of -182
1/15/2006 4:10:02 PM||Attempting to communicate with [setiboinc.ssl.berkeley.edu] timed out
1/15/2006 4:10:02 PM|SETI@home|Scheduler request to http://setiboinc.ssl.berkeley.edu/sah_cgi/cgi failed with a return value of -182
1/15/2006 4:10:02 PM|SETI@home|No schedulers responded
1/15/2006 6:10:27 PM|SETI@home|Sending scheduler request to http://setiboinc.ssl.berkeley.edu/sah_cgi/cgi
1/15/2006 6:10:27 PM|SETI@home|Reason: Requested by user
1/15/2006 6:10:27 PM|SETI@home|Requesting 8640 seconds of new work
1/15/2006 6:10:42 PM|SETI@home|Scheduler request to http://setiboinc.ssl.berkeley.edu/sah_cgi/cgi succeeded
1/15/2006 6:10:42 PM|SETI@home|No start tag in scheduler reply
1/15/2006 6:10:42 PM|SETI@home|Can't parse scheduler reply
1/15/2006 8:28:07 PM|SETI@home|Sending scheduler request to http://setiboinc.ssl.berkeley.edu/sah_cgi/cgi
1/15/2006 8:28:07 PM|SETI@home|Reason: Requested by user
1/15/2006 8:28:07 PM|SETI@home|Requesting 8640 seconds of new work
1/15/2006 8:33:14 PM||Attempting to communicate with [setiboinc.ssl.berkeley.edu] timed out
1/15/2006 8:33:17 PM|SETI@home|Scheduler request to http://setiboinc.ssl.berkeley.edu/sah_cgi/cgi failed with a return value of -182
1/15/2006 8:33:17 PM|SETI@home|No schedulers responded
1/15/2006 8:34:17 PM|SETI@home|Fetching master file
1/15/2006 8:34:22 PM|SETI@home|Master file download succeeded
1/15/2006 8:34:27 PM|SETI@home|Sending scheduler request to http://setiboinc.ssl.berkeley.edu/sah_cgi/cgi
1/15/2006 8:34:27 PM|SETI@home|Reason: Requested by user
1/15/2006 8:34:27 PM|SETI@home|Requesting 8640 seconds of new work

---

1/15/2006 4:10:02 PM|SETI@home|Scheduler request to http://setiboinc.ssl.berkeley.edu/sah_cgi/cgi failed with a return value of -182

This is a timeout error. What do you get if you do a trace on your connection? If there's a slowdown somewhere along the way, you might think about dodging around it, using a different net path by using a a public proxy to connect. You can find a list of them at this web site, you may have to experiment before you get one that would work for you.
The proxy settings in the BOINC manager are under Options in the menu bar, find the HTTP Proxy tab.


MJ

---

Trace ??? I can't ping any of the seti addresses

---

Trace ??? I can't ping any of the seti addresses

Can you ping any addresses?

Can you ping 66.28.250.125?

---

Trace ??? I can't ping any of the seti addresses

Tracert setiboinc.ssl.berkeley.edu

This should give a trace of the packet routing.

You say you cannot ping any of the SETI addresses, what do you get exactly when you try?

---

Pinging 66.28.250.123 with 32 bits of data

reply from 69.44.192.1 destination net unreachable
request timed out

---

1 158ms 199ms 100ms dsldevice.lan [192.168.1.254]
2 48ms 47ms 48ms 10.0.0.1
3 47ms 47ms 44ms gateway192-1.chouteautel.com[69.44.192.1]
4 * * * requst timed out

---

I would talk to your ISP or if you're part of a large copmpany, your network people.

You seem to be getting through your gateway to the internet, then the first node you reach which should be your ISP (or somewhere in your company), cannot go further.

Just for info, if you do ping /a 66.28.250.125 does it resolve the ip address to a name?

---

I would talk to your ISP or if you're part of a large copmpany, your network people.

You seem to be getting through your gateway to the internet, then the first node you reach which should be your ISP (or somewhere in your company), cannot go further.

Just for info, if you do ping /a 66.28.250.125 does it resolve the ip address to a name?

No

---

It appears that his ISP (FairPoint Communication) blocks in bound Ping and Tracert commands at their boundary with Williams Communications in Tulsa, OK.

And his answer confirms that they block out bound requests also.

Not uncommon for smaller DSL ISP's and Dial-up ISP's to do that.
The destination net unreachable is the normal response when they block.
So Ping and Tracert will not get him anywhere.

You will have to try a proxy server. See link in prior posts.

If you you have the ability, try a dial-up backup on the system and see if you can connect that way.

If you have a router, go into its setup and manually set the MTU to 1500 and try that. Then try MTU= 1400 and MTU= 576, and see if that helps. If not set it back to 1500.

If no joy, then go to http://www.dslreports.com/tweaks and run their tweak test. And see what it tells you. Post the results here to see if there are any clues. Interested in the maximum MTU and MSS, if MTU Path discovery is enabled and if Black Hole Detection is enabled.

There are fixes in the next release version of BOINC that might solve the problem, or at least give a more informative error message. But the one you are getting sure looks like some sort of corruption.

It appears that his ISP (FairPoint Communication) blocks in bound Ping and Tracert commands at their boundary with Williams Communications in Tulsa, OK.

And his answer confirms that they block out bound requests also.

<stuff deleted>

I'll bet they actually block all ICMP, which causes all kinds of heartache.

---