I suspect this is probably related to an HTTP 500 error condition I investigated on the CPDN coupled model spinup project.

When a request is sent to the scheduler you can get an HTTP 100-continue intermediate response indicating that the scheduler has received your request and is working on it. When the scheduler finishes processing the request it sends the reply, which you receive as an HTTP 200-OK message.

BOINC was generating the 500 error and closing the socket after receiving the 100-continue message. This prevented the 200-OK message from getting through. I submitted a change to fix this a couple of days ago, but it hasn't been checked in yet.

One user is experiencing this all the time on all hosts, others are getting it intermittently but most never get it.

@Thyme Lawn
Hi there. Your change, has it been checked in yet? What version does it appear in. There are quite a few folks with this problem and we would like to try and get it sorted. If you have found it and fixed it and a release is available then it would be good to tell them to try it out.
Thanks

Ian

---

One more 500 error
Ever since I updated my work computer to 5.2.13
Ver 4.? worked fine. (Home computer works fine with 5.4.13)

1/8/2006 9:15:30 AM|SETI@home|Fetching master file
1/8/2006 9:15:35 AM|SETI@home|Master file download succeeded
1/8/2006 9:15:40 AM|SETI@home|Sending scheduler request to http://setiboinc.ssl.berkeley.edu/sah_cgi/cgi
1/8/2006 9:15:40 AM|SETI@home|Reason: To fetch work
1/8/2006 9:15:40 AM|SETI@home|Requesting 86400 seconds of new work
1/8/2006 9:15:45 AM|SETI@home|Scheduler request to http://setiboinc.ssl.berkeley.edu/sah_cgi/cgi failed with a return value of 500
1/8/2006 9:15:45 AM|SETI@home|No schedulers responded

Red Wolf

---

One more 500 error
Ever since I updated my work computer to 5.2.13
1/8/2006 9:15:45 AM|SETI@home|No schedulers responded

Man, this problem has to be pissing of a few people and lots of people who have just given up on BOINC, not knowing how or wanting to access the message boards. Almost as much as it has those who have been trying to help sort out what it going on.

BOINC detected the software change and requested an update of your Master File and got it OK. (So communications channels to Project servers is OK.) What failed is the attempt to connect to the Scheduler afterward.

There could be some software Firewall problems or router problems causing this, as directly connecting to the modem often helps get past this problem. There could also be some sort of issue BOINC sending back information that the server does not like, and for security reasons does not recognize your current BOINC as a valid user.

[edit]Oops, thats a company Proxy in your case. I remember reading that there are some issues going through some Proxy servers. There may be a problem here with the schedulers using to different IP addresses.

Ya, at work I'm going through a company password protected proxy. Is 5.2 boinc handleing the proxy user/pass correctly?? Maybe not using it for the schedual conection?

I had to uninstall/delete the bonic folder to roll back to 4.45 to get boinc to work again. I'm up and running again at work, so I don't think it is the proxy or the seti server.

---

I had to uninstall/delete the bonic folder to roll back to 4.45 to get boinc to work again.

Just ran across this post that may or may not describe the same problems.

500 error

No details of which one of the many error 500 problems. I have been looking to see what else I can find out about what he is talking about. I know there are some changes in the works to use a different set of error codes and messages that are more informative about these connection errors. It is just a catch all error that the server did not respond. But to what? And why?

Nothing I have found so far explains why this problem starts on one machine and not the one next to it also as they are both using the same communications link and the same router. A protocol error would not explain this difference, unless is description left out a lot of the facts and details.

if you search at seti for "500" i'm sure you'll get lots of results, seti has similar problems a while ago, with quite a few users in similar situations

there are obviously still some experiencing this problem :(

@Thyme Lawn
Hi there. Your change, has it been checked in yet? What version does it appear in. There are quite a few folks with this problem and we would like to try and get it sorted. If you have found it and fixed it and a release is available then it would be good to tell them to try it out.

David checked it in on Friday. From the CVS tags it should be in 5.3.11

---

"The ultimate test of a moral society is the kind of world that it leaves to its children." - Dietrich Bonhoeffer

Be sure I'll test it ;-)

So does it work now before I go to all the trouble to installed the new version?

---

Everyone, please look at this post that Wander Saito made on the Seti helpdesk forums. You may have benefit of it.

---

I posted this at Seti too.
OK I did an experiment around this 500 problem.

I have saved the boincview logs and the ethereal trace if anyone wants them but they tell this story.

All projects (seti, LHC,CPDN,Einstein) are working fine and updating etc as one would want.

I use linux to route. So I made it a router that had a 576 sized MTU on two of its nics: my side and Internet side.
All still worked OK.

I made sure windows was saying do not fragment.

I turned off pinging on my linux router.

All hells breaks loose.

I get boinc error -182 from LHC. I get http error from Einstein and guess...I get the infamous 500 from seti.

I had just created the router problem we have talked about for some time.

I reset MTU sizes and turned on ping and hey ho it all worked again.

So where does that leave us. As Ned says - combination of bad MTU sizes and not handling ping on someones route and its all over: use a proxy?

---

Nice experiment, Tigher. Thank you.

Anyway - as I told before, this should be software for wide public and although I'll be probably able to tweak BOINC to run, I will not do it. I will wait for BOINC release, which can talk with servers by itself. In the meantime I will support seti through BOINC 4.71, which version is the last working with my company proxy.

Btw - tried BOINC 5.3.15 :
****************************************
30.1.2006 6:45:25|LHC@home|Sending scheduler request to http://lhcathome-sched1.cern.ch/scheduler/cgi
30.1.2006 6:45:25|LHC@home|Reason: Requested by user
30.1.2006 6:45:25|LHC@home|(not requesting new work or reporting completed tasks)
30.1.2006 6:45:27||HTTP error: Send failed since rewinding of the data stream failed
30.1.2006 6:45:30|LHC@home|Scheduler request to http://lhcathome-sched1.cern.ch/scheduler/cgi failed: http error
30.1.2006 6:45:30|LHC@home|No schedulers responded
30.1.2006 6:45:30|LHC@home|Deferring scheduler requests for 1 minutes and 0 seconds

30.1.2006 6:49:05|SETI@home|Sending scheduler request to http://setiboinc.ssl.berkeley.edu/sah_cgi/cgi
30.1.2006 6:49:05|SETI@home|Reason: Requested by user
30.1.2006 6:49:05|SETI@home|Reporting 1 tasks
30.1.2006 6:49:08||HTTP error: Send failed since rewinding of the data stream failed
30.1.2006 6:49:10|SETI@home|Scheduler request to http://setiboinc.ssl.berkeley.edu/sah_cgi/cgi failed: http error
30.1.2006 6:49:10|SETI@home|No schedulers responded
30.1.2006 6:49:10|SETI@home|Deferring scheduler requests for 1 minutes and 0 seconds

****************************************

Back to the future (Boinc 4.71)

---

company proxy.

Can you do a fee pings of the following and tell us which ones work OK and the average ping time?

ping 128.32.18.152
ping setiathome.ssl.berkeley.edu
ping 128.32.18.174
ping setiboinc.ssl.berkeley.edu
ping 66.28.250.125
ping setiboincdata.ssl.berkeley.edu
Ping -f -l 1428 setiboincdata.ssl.berkeley.edu

If you can not ping all of them and get DNS resolution of the ones with names, then you most likely will not be able to work through the company firewall proxy router, as they are cutting off ping requests for some reason in an improper way so that PATH MTU Discovery does not work correctly.

Then try the following Trace Route commands and see if they can reach through the proxy server all the way to the seti servers.

tracert setiboinc.ssl.berkeley.edu
tracert setiboincdata.ssl.berkeley.edu

As none of us trying to help solve this type of problem can set down at your systems and run Ethereal network traces and hook up to the line on the Public side of your companies proxy server, there is not much we can do to find out why you are having problems. Which also means the problem will not get fixed for others who have the same problem.

If you still have BOINC 5.2.x still running on a Windows system, can you try an experiment and post back with the result to see if it makes any difference? Use the program DrTCP to set the "Path MTU Discovery" and "Black Hole Detection" to NO and then reboot the system and test if it can get through. Then change those setting back to their original values Yes/No and reboot again. This at least might give us one small clue or rule out one of the minor theories as to what might be going wrong.

I have some of the technical details about this error in the wiki now. Tigher gave me a start that I am still formatting (bear with me), but you can see a little about what we know and are trying to learn.

For the networking mavens, if you have constructive suggestions I am all ears ...

See here There is new summary information at the top, and the new block at the bottom.

One thing I have been wondering is if we should split some of it out or not ...

---

One thing I have been wondering is if we should split some of it out or not ...

great info paul :)

as for organisation, my view is that when it gets bigger and too complex, then split it into sections for each error or type or error (possibly something else thou) so that even if a user doesn't know what an error means, they can still find relavent helpful info

company proxy.

Can you do a fee pings...

Yes Jack, I will do it. Unfortunately I'm sick now and stay at home.
Will try it as soon as return to work (should be day after tomorrow).

---

And my results: from the first two pings.

H:\\>ping 128.32.18.152

Pinging 128.32.18.152 with 32 bytes of data:

Request timed out.
Request timed out.
Request timed out.
Request timed out.

Ping statistics for 128.32.18.152:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),

H:\\>ping setiathome.ssl.berkeley.edu

Pinging setiathome.ssl.berkeley.edu [128.32.18.151] with 32 bytes of data:

Request timed out.
Request timed out.
Request timed out.
Request timed out.

Ping statistics for 128.32.18.151:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),

---

Pinging 128.32.18.152 with 32 bytes of data:

Request timed out.

Means you either do not have a connection to the Internet or a proxy server firewall router is blocking all ping type requests.

Try doing a ping 127.0.0.1 and it should work as that is just a ping of your own systems internal software TCP/IP stack. If that does not work, you would not be able to access much of anything on the Internet from that system.

Then see if you can do a few trace route commands. These might tell you how for you can get out before being blocked.

tracert 128.32.18.152
tracert 128.32.18.174
tracert setiboincdata.ssl.berkeley.edu

The first is the setiathome message board server, the second is the BOINC/setiathome scheduler and the last is the upload/download server. These should tell you where in the chain of network routers you are being blocked, and most likely will be the first one at the company firewall. If that happens, then you do not have permission from the company to run BOINC and/or Setiathome through their network! You would have to take that issue up with the company IT department.

The last command should resolve the URL to an IP address 66.28.250.125 before starting the trace route. If not, then there is a basic problem accessing the DNS servers.

Your problem sounds like one version 5.2.x problem that is being worked on by the developers, but there is no fix for yet even in the test versions. It occurs with some company proxy firewalls that require a password authentication. One way around the problem is to set up an HTTP Proxy on your own system and have BOINC connect to it. Then use the HTTP Proxy to connect to the company firewall proxy using the password authentication if necessary. This has worked for some people. But may be a bit more than you want to try.

Part 1

Can you do a fee pings of the following and tell us which ones work OK and the average ping time?

ping 128.32.18.152
ping setiathome.ssl.berkeley.edu
ping 128.32.18.174
ping setiboinc.ssl.berkeley.edu
ping 66.28.250.125
ping setiboincdata.ssl.berkeley.edu
Ping -f -l 1428 setiboincdata.ssl.berkeley.edu

Ping results (unfortunately in czech language):

***** ping 128.32.18.152
Prikaz PING na 128.32.18.152 s delkou 32 bajtu:
Odpoved od 192.168.74.253: Cilova sit neni dostupna. (Target network not available)
Vyprsel casovy limit zadosti. (Request timed out)
Odpoved od 192.168.74.253: Cilova sit neni dostupna.
Vyprsel casovy limit zadosti.

Statistika ping pro 128.32.18.152:
Pakety: Odeslane = 4, Prijate = 2, Ztracene = 2 (ztrata 50%), (sent/received/lost)
Priblizna doba do prijeti odezvy v milisekundach:
Minimum = 0ms, Maximum = 0ms, Prumer = 0ms

***** ping setiathome.ssl.berkeley.edu
Prikaz PING na setiathome.ssl.berkeley.edu [128.32.18.151] s delkou 32 bajtu:

Odpoved od 192.168.74.253: Cilova sit neni dostupna. (Target network not available)
Odpoved od 192.168.74.253: Cilova sit neni dostupna.
Odpoved od 192.168.74.253: Cilova sit neni dostupna.
Odpoved od 192.168.74.253: Cilova sit neni dostupna.

Statistika ping pro 128.32.18.151:
Pakety: Odeslane = 4, Prijate = 4, Ztracene = 0 (ztrata 0%),
Priblizna doba do prijeti odezvy v milisekundach:
Minimum = 0ms, Maximum = 0ms, Prumer = 0ms

***** ping 128.32.18.174
Prikaz PING na 128.32.18.174 s delkou 32 bajtu:

Odpoved od 192.168.74.253: Cilova sit neni dostupna.
Odpoved od 192.168.74.253: Cilova sit neni dostupna.
Odpoved od 192.168.74.253: Cilova sit neni dostupna.
Odpoved od 192.168.74.253: Cilova sit neni dostupna.

Statistika ping pro 128.32.18.174:
Pakety: Odeslane = 4, Prijate = 4, Ztracene = 0 (ztrata 0%),
Priblizna doba do prijeti odezvy v milisekundach:
Minimum = 0ms, Maximum = 0ms, Prumer = 0ms

***** ping setiboinc.ssl.berkeley.edu
Prikaz PING na galileo.ssl.berkeley.edu [128.32.18.173] s delkou 32 bajtu:

Odpoved od 192.168.74.253: Cilova sit neni dostupna.
Vyprsel casovy limit zadosti.
Odpoved od 192.168.74.253: Cilova sit neni dostupna.
Odpoved od 192.168.74.253: Cilova sit neni dostupna.

Statistika ping pro 128.32.18.173:
Pakety: Odeslane = 4, Prijate = 3, Ztracene = 1 (ztrata 25%),
Priblizna doba do prijeti odezvy v milisekundach:
Minimum = 0ms, Maximum = 0ms, Prumer = 0ms

***** ping 66.28.250.125
Prikaz PING na 66.28.250.125 s delkou 32 bajtu:

Odpoved od 192.168.74.253: Cilova sit neni dostupna.

Odpoved od 192.168.74.253: Cilova sit neni dostupna.
Odpoved od 192.168.74.253: Cilova sit neni dostupna.
Odpoved od 192.168.74.253: Cilova sit neni dostupna.

Statistika ping pro 66.28.250.125:
Pakety: Odeslane = 4, Prijate = 4, Ztracene = 0 (ztrata 0%),
Priblizna doba do prijeti odezvy v milisekundach:
Minimum = 0ms, Maximum = 0ms, Prumer = 0ms

***** ping setiboincdata.ssl.berkeley.edu
Prikaz PING na setiboincdata.ssl.berkeley.edu [66.28.250.125] s delkou 32 bajtu:

Odpoved od 192.168.74.253: Cilova sit neni dostupna.
Vyprsel casovy limit zadosti.
Odpoved od 192.168.74.253: Cilova sit neni dostupna.
Odpoved od 192.168.74.253: Cilova sit neni dostupna.

Statistika ping pro 66.28.250.125:
Pakety: Odeslane = 4, Prijate = 3, Ztracene = 1 (ztrata 25%),
Priblizna doba do prijeti odezvy v milisekundach:
Minimum = 0ms, Maximum = 0ms, Prumer = 0ms

***** Ping -f -l 1428 setiboincdata.ssl.berkeley.edu
Prikaz PING na setiboincdata.ssl.berkeley.edu [66.28.250.125] s delkou 1428 bajtů:

Odpoved od 192.168.74.253: Cilova sit neni dostupna.
Vyprsel casovy limit zadosti.
Odpoved od 192.168.74.253: Cilova sit neni dostupna.
Odpoved od 192.168.74.253: Cilova sit neni dostupna.

Statistika ping pro 66.28.250.125:
Pakety: Odeslane = 4, Prijate = 3, Ztracene = 1 (ztrata 25%),
Priblizna doba do prijeti odezvy v milisekundach:
Minimum = 0ms, Maximum = 0ms, Prumer = 0ms

---

Part2

Then try the following Trace Route commands and see if they can reach through the proxy server all the way to the seti servers.

tracert setiboinc.ssl.berkeley.edu
tracert setiboincdata.ssl.berkeley.edu

***** tracert setiboinc.ssl.berkeley.edu
Vypis trasy k galileo.ssl.berkeley.edu [128.32.18.173]
s nejvyse 30 smerovanimi:

1 < 1 ms < 1 ms < 1 ms 192.168.78.254
2 192.168.74.253 hlasi: Cilova sit neni dostupna. (Target network not available)

Trasovani bylo dokonceno. (Tracing finished)

***** tracert setiboincdata.ssl.berkeley.edu
Vypis trasy k setiboincdata.ssl.berkeley.edu [66.28.250.125]
s nejvyse 30 smerovanimi:

1 < 1 ms < 1 ms < 1 ms 192.168.78.254
2 192.168.74.253 hlasi: Cilova sit neni dostupna.

Trasovani bylo dokonceno.

***** tracert 128.32.18.152
Vypis trasy k klaatu.ssl.berkeley.edu [128.32.18.152]
s nejvyse 30 smerovanimi:

1 < 1 ms < 1 ms < 1 ms 192.168.78.254
2 192.168.74.253 hlasi: Cilova sit neni dostupna.

Trasovani bylo dokonceno.

***** tracert 128.32.18.174
Vypis trasy k jill.ssl.berkeley.edu [128.32.18.174]
s nejvyse 30 smerovanimi:

1 < 1 ms < 1 ms < 1 ms 192.168.78.254
2 192.168.74.253 hlasi: Cilova sit neni dostupna.

Trasovani bylo dokonceno.

***** ping 127.0.0.1
Prikaz PING na 127.0.0.1 s delkou 32 bajtu:

Odpoved od 127.0.0.1: bajty=32 cas < 1ms TTL=128
Odpoved od 127.0.0.1: bajty=32 cas < 1ms TTL=128
Odpoved od 127.0.0.1: bajty=32 cas < 1ms TTL=128
Odpoved od 127.0.0.1: bajty=32 cas < 1ms TTL=128

Statistika ping pro 127.0.0.1:
Pakety: Odeslane = 4, Prijate = 4, Ztracene = 0 (ztrata 0%),
Priblizna doba do prijeti odezvy v milisekundach:
Minimum = 0ms, Maximum = 0ms, Prumer = 0ms

---