Howdy all!!!

Whenever I use 5.2.13, it will download work and crunch it fine, however; it will not upload it. I have checked all my computer settings, have given BOINC full access through the firewall etc.

In order to get my computer to upload information, I have to stick with version 4.45.

Any suggestions would be helpful.

---

Elmerfudd Seeker of ET Wabbits

"Burn the land and boil the sea. You can't take the sky from me." -Firefly

What kind of errors do you get? Do you still have some examples from the Messages tab at hand? It would be useful to add such information.

---

What kind of errors do you get? Do you still have some examples from the Messages tab at hand? It would be useful to add such information.

I don't get specific errors. If you look in the TRANSFER tab, it shows all of the work that is being uploaded, but always says the communication is delayed for HH:MM:SS. It appears that a small portion (<1%) is transmitted, but never gets any further than that.

I finally went back to version 4.45 so that I could continue crunching.

Thanks

---

Elmerfudd Seeker of ET Wabbits

"Burn the land and boil the sea. You can't take the sky from me." -Firefly

Uhm, for which project(s) and when was this? Hopefully not Seti after they had a 2 day outage due to the science database merge? It is then always extremely busy on the servers, so uploads and downloads will be deferred.

---

There are several threads on this type of problem in the Setiathome boards going back several months. While some people have had this type of problem for some time, most having it now only started seeing it around the first of the year. So far for most of them, no solution has been found, other that doing what you did.

For a few with older Linksys routers, updating the router firmware has fixed their MTU problems. A few have found deleting some BOINC work files has got things working for a short time. Others have connected each system directly to their DSL/Cable modem and got a system to work. Some have been able to find a proxy server that works for them. Problems found in the BOINC code within the connection logic did not fix the problems. The error messages in test versions all keep pointing back to "errors" detected by the LibcURL.dll that handles communications in the new version of BOINC. The problem is being seen by users of other Projects.

One problem with getting information is that the users seem to be paranoid about posting tracert information in the forums (or don't know how to do it) or giving detailed information on their network hardware and Internet connection. Not that they even understand what all of it means. Getting any kind of TCP trace from these users would be very useful, but almost impossible to walk them through setting up and getting one.

The biggest problem is that no one with experience looking into these types of problems as been able to get physical access to the failing systems, to see what is really going on. Most efforts have been trying to walk users through some basic checks using PING and looking at Message logs, and trying simple solutions to see if they help.

I have been suspecting some sort of problem with delays in the Internet traffic causing LibcURL problems. But that would not explain why many of the people having problems have one (and only one) system that works, yet all of their other systems on their local network can not send data and get the different error messages. Its not a case of not being able to connect to the server, a TCP/IP session is being made. The server is telling them to send the data. It is just a problem trying to send data packets and.or get acknowledgments back. Part of the problem could be the servers dropping connections, but why would other Projects be seeing the same problems.

Lack of support at Berkeley has prevented getting any information such as "is the packets of data even getting there" and what is the server doing with them. It would be possible to set up a TCP trace at their end and filter the IP address of a failing user. That would give some big clues, but would take a lot of effort and time on their part. Something the limited staff there do not have much time for. I was hoping that by now, one of the other Projects would have collected some useful information.

So most efforts are on hold, waiting for a break and new information.

I'm crunching data for both Setiathome and Climateprediction, and it happens to both of them. Any time I try to run from behind my corporate firewall I am unable to upload or download data any time I use the 5.x series software. The old 4.x software works fine with the same proxy settings. All attempts to connect come back with the message "Scheduler request to xxx failed with a return value of 417".

In order to upload and download data I have to connect directly to the Internet from home rather than going through the corporate network. So every few days when my Setiathome data is almost all crunched I have to disconnect from the network and let it run 'naked' for a night to get some new data. It's a pain in the neck.

---

Any time I try to run from behind my corporate firewall...
"Scheduler request to xxx failed with a return value of 417".

You must be stuck behind a proxy that does not know how to handle BOINC's HTTP/1.1 version, "Expect : 100 Continue" (or can not handle the BOINC servers slow responses to it) and is sending back the "Expectation Failed" error 417. And BOINC 5 currently does not know how to continue with the transfer, as it should continue it in this case, an aparent flaw in BOINC's handler. Hopefully this flaw will be fixed in the next version (or two) and it will be able to "work around" proxy servers that have this problem.

Is there any way you could try other proxy servers?

Any time I try to run from behind my corporate firewall...
"Scheduler request to xxx failed with a return value of 417".

You must be stuck behind a proxy that does not know how to handle BOINC's HTTP/1.1 version, "Expect : 100 Continue" (or can not handle the BOINC servers slow responses to it) and is sending back the "Expectation Failed" error 417. And BOINC 5 currently does not know how to continue with the transfer, as it should continue it in this case, an aparent flaw in BOINC's handler. Hopefully this flaw will be fixed in the next version (or two) and it will be able to "work around" proxy servers that have this problem.

Is there any way you could try other proxy servers?

Unfortunately, no. I guess I'm just stuck doing the direct-connection-every-few-days workaround until BOINC gets fixed. Do you know if there's any official bug-reporting I need to do to make sure it's on the list of things to be fixed?

---

Any time I try to run from behind my corporate firewall...
"Scheduler request to xxx failed with a return value of 417".

You must be stuck behind a proxy that does not know how to handle BOINC's HTTP/1.1 version, "Expect : 100 Continue" (or can not handle the BOINC servers slow responses to it) and is sending back the "Expectation Failed" error 417. And BOINC 5 currently does not know how to continue with the transfer, as it should continue it in this case, an aparent flaw in BOINC's handler. Hopefully this flaw will be fixed in the next version (or two) and it will be able to "work around" proxy servers that have this problem.

Is there any way you could try other proxy servers?

Unfortunately, no. I guess I'm just stuck doing the direct-connection-every-few-days workaround until BOINC gets fixed. Do you know if there's any official bug-reporting I need to do to make sure it's on the list of things to be fixed?

This one is thoertically fixed in the code now...just have to get the next build and see if it actually works.

---

BOINC WIKI

BOINCing since 2002/12/8

Any time I try to run from behind my corporate firewall...
"Scheduler request to xxx failed with a return value of 417".

You must be stuck behind a proxy that does not know how to handle BOINC's HTTP/1.1 version, "Expect : 100 Continue" (or can not handle the BOINC servers slow responses to it) and is sending back the "Expectation Failed" error 417. And BOINC 5 currently does not know how to continue with the transfer, as it should continue it in this case, an aparent flaw in BOINC's handler. Hopefully this flaw will be fixed in the next version (or two) and it will be able to "work around" proxy servers that have this problem.

Is there any way you could try other proxy servers?

Unfortunately, no. I guess I'm just stuck doing the direct-connection-every-few-days workaround until BOINC gets fixed. Do you know if there's any official bug-reporting I need to do to make sure it's on the list of things to be fixed?

If you want to try the patched version as of 5.2.13 then mail me at john_brown_gordon at ntlworld.com and I will send you a link and instructions. It is intended to force 1.1 http instead of letting the client select. On the basis of ALL the traces I have those where the cc chooses 1.0 lead to failure. All those where 1.1 is chosen lead to success.

If you are willing I would like to collect traces before you make the change just to get my database of problems a little larger. Then perhaps afterwards another trace to see the difference. Let me know if you will do this.

Oh and please tell me what router you use...make, model, firmware version?

General.

On the topic of what is wrong btw I have to say that is still not clear. Even though the cc sent a expect 100 continue the server plain ignored it anyway. So whilst this may be a small step forward there may be work to at the server end also yet. It is clear that boinc is not working in accordance with RFC 2616.

Does this thread belong in the client area? Can it be moved?

---

oooops double! Sorry!

---