Does this page help?

Thank you for the link.

There is written:
" If you do not have access to the source code for these systems, the only thing you can do is refer the problem to technical support people at the companies that developed the systems."

This is exactly what I'm doing :]

Spok

---

The BOINC developers just pass on this information to the makers of libcurl. Those are the real people you should contact. ;-)

---

Spok, can you please leave information for these questions?

1) OS and version
2) BOINC version
3) personal firewall?
4) separate firewall?
5) networking setup: router? NAT?
6) ISP

Also, I got this answer from David Anderson:

First, let's clarify whether the problems you describe are
1) between the Manager and the core client, or
2) between the core client and project servers.
These are completely different things.

(1) Doesn't use HTTP, so 400/403/500 errors are not relevant
(these are HTTP status codes).
We changed from port 1043 to 31416 in version 5.3.6.

(2) We switched to libcurl as of 5.1.2.
All communication between core client and outside servers
goes over HTTP, using libcurl.
So the problems you describe are probably libcurl-related.

Debugging info (including printing HTTP request and reply headers)
is enabled by <http_debug/>.
First step: have the user set this flag, and get the resulting output.

To set <http_debug/>, exit BOINC completely.
Navigate to your BOINC directory.
Make a file called cc_config.xml (with Notepad).
Add into it:

<cc_config>
    <log_flags>
        <http_debug>1</http_debug>
    </log_flags>
</cc_config>

Save the file, make sure it doesn't get the *.txt extension.
Restart BOINC.

Now when you run into trouble, it will be written to stderrdae.txt in your BOINC directory. I am very interested in that file, so send it to me at elst93 at gmail dot com (if you want to compress it, use something different than ZIP, as gmail doesn't allow ZIPs to be sent/received. RARs are alright.)
I will send it what is needed through to the developers. (This does need a BOINC version 5.x.x to succeed!)

---

Correction in the cc_config.xml file:

<cc_config>
    <log_flags>
        <http_debug>1</http_debug>
    </log_flags>
</cc_config>

This one will make it log correctly.

---

I receive the exact same messages when I try to use the new versions of Boinc at my work computer as Spok highlights bellow.
As a note I'm using Windows XP Pro SP2. I've tried several versions of Boinc 5.x.x latest was 5.4.11. (4.x.x worked fine). There is no personal firewall on the computer I use, I am not sure what my company uses for a corporate firewall. The company has an http proxy with an individual user name and password. I have no idea what the ISP is, all I know is everything is routed through corporate headquarters two states away before going out to the world wide web. Trace route fails trying to go past the 13th hop to anywhere outside the internal network (google.com yahoo.com, msn.com it shows the same route for all). Total delay is less then 30 ms to that point so I'm guessing they are all internal company routers.


As an instersting experiment, I re-installed boinic as a "single user". this seemed to change the response.

08/15/06 13:35:34|SETI@home|Sending scheduler request to http://setiboinc.ssl.berkeley.edu/sah_cgi/cgi
08/15/06 13:35:34|SETI@home|Reason: Requested by user
08/15/06 13:35:34|SETI@home|(not requesting new work or reporting completed tasks)
08/15/06 13:36:25|SETI@home|Scheduler request failed: HTTP service unavailable
08/15/06 13:36:25|SETI@home|Deferring scheduler requests for 1 hours, 56 minutes and 35 seconds


As one more test run I deleted the user name and password from the http and got a different message. (I did not expect that to work but nothing else did either.)


08/15/06 13:36:40|SETI@home|Sending scheduler request to http://setiboinc.ssl.berkeley.edu/sah_cgi/cgi
08/15/06 13:36:40|SETI@home|Reason: Requested by user
08/15/06 13:36:40|SETI@home|(not requesting new work or reporting completed tasks)
08/15/06 13:37:02||Project communication failed: attempting access to reference site
08/15/06 13:37:07|SETI@home|Scheduler request failed: couldn't connect to server
08/15/06 13:37:07|SETI@home|Deferring scheduler requests for 2 hours, 31 minutes and 45 seconds

---

This was recorded after I made cc_config.xml

stderrdae.txt

2006-08-15 13:54:39 [SETI@home] Scheduler request failed: HTTP service unavailable

stderrgui.txt

(blank)

stdoutdae.txt

To pause/resume tasks hit CTRL-C, to exit hit CTRL-BREAK
2006-08-15 13:53:32 [---] Starting BOINC client version 5.4.11 for windows_intelx86
2006-08-15 13:53:32 [---] libcurl/7.15.3 OpenSSL/0.9.8a zlib/1.2.3
2006-08-15 13:53:32 [---] Data directory: C:\\Program Files\\BOINC
2006-08-15 13:53:32 [---] Processor: 1 GenuineIntel Intel(R) Pentium(R) 4 CPU 2.80GHz
2006-08-15 13:53:32 [---] Memory: 502.07 MB physical, 1.20 GB virtual
2006-08-15 13:53:32 [---] Disk: 37.17 GB total, 18.05 GB free
2006-08-15 13:53:32 [SETI@home] URL: http://setiathome.berkeley.edu/; Computer ID: 2388516; location: home; project prefs: home
2006-08-15 13:53:32 [---] General prefs: from SETI@home (last modified 2004-12-22 07:48:18)
2006-08-15 13:53:32 [---] General prefs: using separate prefs for home
2006-08-15 13:53:32 [---] Local control only allowed
2006-08-15 13:53:32 [---] Listening on port 31416
2006-08-15 13:53:32 [SETI@home] Resuming task 15ap06ab.13135.8752.522150.3.127_0 using setiathome_enhanced version 515
2006-08-15 13:53:48 [SETI@home] Sending scheduler request to http://setiboinc.ssl.berkeley.edu/sah_cgi/cgi
2006-08-15 13:53:48 [SETI@home] Reason: Requested by user
2006-08-15 13:53:48 [SETI@home] (not requesting new work or reporting completed tasks)
2006-08-15 13:54:39 [SETI@home] Scheduler request failed: HTTP service unavailable
2006-08-15 13:54:39 [SETI@home] Deferring scheduler requests for 1 minutes and 0 seconds
2006-08-15 13:55:41 [SETI@home] Fetching scheduler list
2006-08-15 13:55:47 [SETI@home] Scheduler list download succeeded
2006-08-15 13:55:52 [SETI@home] Sending scheduler request to http://setiboinc.ssl.berkeley.edu/sah_cgi/cgi
2006-08-15 13:55:52 [SETI@home] Reason: Requested by user
2006-08-15 13:55:52 [SETI@home] (not requesting new work or reporting completed tasks)
2006-08-15 13:55:57 [SETI@home] Scheduler request failed: Error 400
2006-08-15 13:55:57 [SETI@home] Deferring scheduler requests for 1 minutes and 0 seconds

stdoutgui.txt

13:53:31: Error: Unknown language -1.

---

Just before few minutes I read that email from David Anderson, but thank you for reminder. I will try it and answer tomorrow in the work. I have some computer experience, so I will not use Notepad for creating xml file and don't worry about txt extension ;-)

Spok, can you please leave information for these questions?

1) OS and version
2) BOINC version
3) personal firewall?
4) separate firewall?
5) networking setup: router? NAT?
6) ISP

Also, I got this answer from David Anderson:

First, let's clarify whether the problems you describe are
1) between the Manager and the core client, or
2) between the core client and project servers.
These are completely different things.

(1) Doesn't use HTTP, so 400/403/500 errors are not relevant
(these are HTTP status codes).
We changed from port 1043 to 31416 in version 5.3.6.

(2) We switched to libcurl as of 5.1.2.
All communication between core client and outside servers
goes over HTTP, using libcurl.
So the problems you describe are probably libcurl-related.

Debugging info (including printing HTTP request and reply headers)
is enabled by <http_debug/>.
First step: have the user set this flag, and get the resulting output.

To set <http_debug/>, exit BOINC completely.
Navigate to your BOINC directory.
Make a file called cc_config.xml (with Notepad).
Add into it:

<cc_config>
    <log_flags>
        <http_debug/>
    </log_flags>
</cc_config>

(Yes, there is a / at the end of http_debug, it needs to be there!)
Save the file, make sure it doesn't get the *.txt extension.
Restart BOINC.

Now when you run into trouble, it will be written to stderrdae.txt in your BOINC directory. I am very interested in that file, so send it to me at elst93 at gmail dot com (if you want to compress it, use something different than ZIP, as gmail doesn't allow ZIPs to be sent. RARs are alright.)
I will send it what is needed through to the developers. (This does need a BOINC version 5.x.x to succeed!)

(If <http_debug/> doesn't work, for one reason or the other, use the following line: <http_debug>1</http_debug> ..)

---

So not to confuse things, Seti did have a total outage today for backup maintenance. This outage is every Tuesday and starts at 17:00 UTC, then lasts anywhere between 2 and 4 hours.

So Red Wolf, it is possible you got "caught" in the normal outage. Can you double check again, at this moment? Seti is back.

---

So, let's start with these questions:
OS: MS WinXP Pro, ver 2002, SP2
BOINC: currently 5.5.13, but you can find in this thread how many versions (testing or released) I tried.
Firewall: Company proxy and NAT. I'm not specialist in networking, so details can tell you after you tell me how to find it. Now I know we have proxy with authentication, and we have local IP adresses (NAT). Maybe there is also firewall and/or router, but I'm not sure. What I know, I cannot ping any site, i.e. google or seti pages, although I can visit it using browser.
ISP: It's also difficult to answer. We are connected to the inet through our sister company in Belgium. No more details now. Tell me how to find more and I will try it.



Regarding cc_config.xml - are you really sure with this syntax?

<cc_config>

<log_flags>

<http_debug>1<http_debug>

</log_flags>

</cc_config>

Shouldn't be "<http_debug>1</http_debug>" instead? You put two possibilities in original message and third in correction, so I'm not sure.

I have this:

2006-08-16 06:33:26 [SETI@home] Sending scheduler request: Requested by user
2006-08-16 06:33:26 [SETI@home] (not requesting new work or reporting completed tasks)
2006-08-16 06:33:26 [---] HTTP_OP::init_post(): 003D4908
2006-08-16 06:33:31 [SETI@home] Scheduler request failed: Error 400
2006-08-16 06:33:31 [SETI@home] Deferring scheduler requests for 1 minutes and 0 seconds
2006-08-16 06:34:32 [SETI@home] Fetching scheduler list
2006-08-16 06:34:37 [SETI@home] Scheduler list download succeeded

in messages tab (and in stdoutdae.txt), but stderrdae.txt stays empty.
Anyway, I will send you all std-.txt files.

Spok

Just before few minutes I read that email from David Anderson, but thank you for reminder. I will try it and answer tomorrow in the work. I have some computer experience, so I will not use Notepad for creating xml file and don't worry about txt extension ;-)

Spok, can you please leave information for these questions?

1) OS and version
2) BOINC version
3) personal firewall?
4) separate firewall?
5) networking setup: router? NAT?
6) ISP

Also, I got this answer from David Anderson:

First, let's clarify whether the problems you describe are
1) between the Manager and the core client, or
2) between the core client and project servers.
These are completely different things.

(1) Doesn't use HTTP, so 400/403/500 errors are not relevant
(these are HTTP status codes).
We changed from port 1043 to 31416 in version 5.3.6.

(2) We switched to libcurl as of 5.1.2.
All communication between core client and outside servers
goes over HTTP, using libcurl.
So the problems you describe are probably libcurl-related.

Debugging info (including printing HTTP request and reply headers)
is enabled by <http_debug/>.
First step: have the user set this flag, and get the resulting output.

To set <http_debug/>, exit BOINC completely.
Navigate to your BOINC directory.
Make a file called cc_config.xml (with Notepad).
Add into it:

<cc_config>
    <log_flags>
        <http_debug/>
    </log_flags>
</cc_config>

(Yes, there is a / at the end of http_debug, it needs to be there!)
Save the file, make sure it doesn't get the *.txt extension.
Restart BOINC.

Now when you run into trouble, it will be written to stderrdae.txt in your BOINC directory. I am very interested in that file, so send it to me at elst93 at gmail dot com (if you want to compress it, use something different than ZIP, as gmail doesn't allow ZIPs to be sent. RARs are alright.)
I will send it what is needed through to the developers. (This does need a BOINC version 5.x.x to succeed!)

(If <http_debug/> doesn't work, for one reason or the other, use the following line: <http_debug>1</http_debug> ..)

---

I can across this page while look for error 466.
I don't know if it's relevant here.

In the post below, I meant "I came across", not "I can across".
My spelling is getting worse.

This page seems to imply that a web server has software problems, when it reports error 500.

Regarding cc_config.xml - are you really sure with this syntax?

<cc_config>

<log_flags>

<http_debug>1<http_debug>

</log_flags>

</cc_config>

Shouldn't be "<http_debug>1</http_debug>" instead? You put two possibilities in original message and third in correction, so I'm not sure.

Yes, I forgot the / in the end tag. My excuses. <http_debug>1</http_debug> is the way to go. So not to confuse people further, I have edited the original post to show the correct log setting.

---

Anyway, even with </http_debug> I have still stderrdae.txt empty.

---

I talked to some of my local IT guys and they said corporate headquarters is running an IDP (intruder detection program?) This has been giving them (local IT) problems with some of there connections between computers for non-standard connections based on whatever parameters the IDP is screening for. For example an FTP connection to an offsite computer is fine but trying to run a remote control on a local machine to read registry settings will get dropped. My guess is the IDP does not screen the 4.x connections but hates 5.x and drops it.

Ageless, I'd rather not go though the trouble of doing all that again. I had 4.45 installed and connected before I ran those tests and after I reinstalled 4.45 I was able to connect again. (edit: It took me about a half hour to do all that and I really can't waste that time during the day. I'm not planning on staying late any time soon either)

---

Spok, so not to take your thread over, keep posting tests for Boinc versions in here and post the other material in this thread.

---

Boinc 5.5.15
WinXP Pro, SP2
Company Proxy, NTML auth.

Not big change, just cannot see error message. If servers are down now, maybe it works. If servers are running, then the Boinc have still problems.


23.8.2006 11:10:41|SETI@home|Sending scheduler request: Requested by user
23.8.2006 11:10:41|SETI@home|(not requesting new work or reporting completed tasks)
23.8.2006 11:10:41||HTTP_OP::init_post(): 003D4908
23.8.2006 11:10:46|SETI@home|Scheduler RPC succeeded [server version 505]
23.8.2006 11:11:52|SETI@home|Started upload of file 16ap06ab.9232.21856.603396.3.84_0_0
23.8.2006 11:11:59||Project communication failed: attempting access to reference site
23.8.2006 11:11:59|SETI@home|Temporarily failed upload of 16ap06ab.9232.21856.603396.3.84_0_0: http error
23.8.2006 11:11:59|SETI@home|Backing off 3 hours, 14 minutes and 54 seconds on upload of file 16ap06ab.9232.21856.603396.3.84_0_0
23.8.2006 11:12:04||Access to reference site succeeded - project servers may be temporarily down.

---

Boinc 5.5.15, WinXP Pro, SP2, Company Proxy, NTML auth.

Not big change, just cannot see error message. If servers are down now, maybe it works. If servers are running, then the Boinc have still problems.

Sorry to say so, but the servers currently communicate well :-(


23.8.2006 11:21:56|SETI@home|Sending scheduler request to http://setiboinc.ssl.berkeley.edu/sah_cgi/cgi
23.8.2006 11:21:56|SETI@home|Reason: Requested by user
23.8.2006 11:21:56|SETI@home|(not requesting new work or reporting completed tasks)
23.8.2006 11:22:01|SETI@home|Scheduler request to http://setiboinc.ssl.berkeley.edu/sah_cgi/cgi succeeded


There is not anymore a note about missing NTLM support in the 5.5.15's version details, as it was during last months. Is there already an attempt to support it built in? Maybe I could give the 5.5.15 a shot too... (also behind NTLM).

Peter

Peter,

Here's the email from Rom about 5.5.14 (the buggered version, 5.5.15 is the fixed one):

Howdy folks,

This new build contains fixes for NTLM auth for http
proxies, and it should fix the work fetch bug with a really large or
negative number for deadline misses.

This build might regress some issues with multiple
proxies nested upon each other. We'll have to keep an eye on that.

---

Peter,

Here's the email from Rom about 5.5.14 (the buggered version, 5.5.15 is the fixed one):

Howdy folks,

This new build contains fixes for NTLM auth for http
proxies, and it should fix the work fetch bug with a really large or
negative number for deadline misses.

This build might regress some issues with multiple
proxies nested upon each other. We'll have to keep an eye on that.

Rom wrote:

Rom wrote on Thu, 11 May 2006 17:45:10 -0700: If you use a proxy server you should hold off on upgrading until we have resolved an issue with NTLM authentication. We should have a fix available in a few days.

Thanks, Jord, I definitely have to take a look at it and report...

Peter