Page 1 of 2

(Client connects) but WU does not download

Posted: Fri Sep 06, 2013 5:19 pm
by gcallantii
I have checked ALL (1,2,3- & 4!) of the assignment servers. with ports 80, and 8080, they all come back OK! My client connects to each of the servers, but then it says it downloads 0 bytes. Just to shout out- I do not have access to my router, gateway, or firewall (I know, that would be the first thing I would try it disabling all of those). But I would think if my browser can connect to the assignment servers on the same ports- why can't my client download WUs? I apologize if someone asked this exact question already- it seemed everyone else was having a slightly different problem (i.e. they would not connect- mine just won't download). Is there possibly a proxy configuration which would fix this?

Thanks!

Code: Select all

*********************** Log Started 2013-09-06T16:27:54Z ***********************
16:27:54:************************* Folding@home Client *************************
16:27:54:      Website: http://folding.stanford.edu/
16:27:54:    Copyright: (c) 2009-2013 Stanford University
16:27:54:       Author: Joseph Coffland <joseph@cauldrondevelopment.com>
16:27:54:         Args: 
16:27:54:       Config: C:/Documents and Settings/gcallant/Application
16:27:54:               Data/FAHClient/config.xml
16:27:54:******************************** Build ********************************
16:27:54:      Version: 7.3.6
16:27:54:         Date: Feb 18 2013
16:27:54:         Time: 15:25:17
16:27:54:      SVN Rev: 3923
16:27:54:       Branch: fah/trunk/client
16:27:54:     Compiler: Intel(R) C++ MSVC 1500 mode 1200
16:27:54:      Options: /TP /nologo /EHa /Qdiag-disable:4297,4103,1786,279 /Ox -arch:SSE
16:27:54:               /QaxSSE2,SSE3,SSSE3,SSE4.1,SSE4.2 /Qopenmp /Qrestrict /MT /Qmkl
16:27:54:     Platform: win32 XP
16:27:54:         Bits: 32
16:27:54:         Mode: Release
16:27:54:******************************* System ********************************
16:27:54:          CPU: Intel(R) Core(TM) i3 CPU 530 @ 2.93GHz
16:27:54:       CPU ID: GenuineIntel Family 6 Model 37 Stepping 2
16:27:54:         CPUs: 4
16:27:54:       Memory: 1.87GiB
16:27:54:  Free Memory: 1.58GiB
16:27:54:      Threads: WINDOWS_THREADS
16:27:54:  Has Battery: false
16:27:54:   On Battery: false
16:27:54:   UTC offset: -7
16:27:54:          PID: 1920
16:27:54:          CWD: C:/WINDOWS/system32
16:27:54:           OS: Microsoft Windows XP Service Pack 3
16:27:54:      OS Arch: X86
16:27:54:         GPUs: 0
16:27:54:         CUDA: Not detected
16:27:54:Win32 Service: true
16:27:54:***********************************************************************
16:27:54:<config>
16:27:54:  <!-- Folding Core -->
16:27:54:  <core-priority v='low'/>
16:27:54:
16:27:54:  <!-- Network -->
16:27:54:  <proxy v=':8080'/>
16:27:54:
16:27:54:  <!-- User Information -->
16:27:54:  <passkey v='********************************'/>
16:27:54:  <team v='111065'/>
16:27:54:  <user v='gcallantii'/>
16:27:54:
16:27:54:  <!-- Folding Slots -->
16:27:54:  <slot id='0' type='CPU'>
16:27:54:    <cpus v='-1'/>
16:27:54:  </slot>
16:27:54:</config>
16:27:54:Trying to access database...
16:27:56:Successfully acquired database lock
16:27:56:Enabled folding slot 00: READY cpu:3
16:27:57:WU00:FS00:Connecting to assign3.stanford.edu:8080
16:31:26:WARNING:WU00:FS00:Failed to get ID from 'assign3.stanford.edu:8080': 10002: Received short response, expected 8 bytes, got 0
16:31:26:WU00:FS00:Connecting to assign4.stanford.edu:80
16:34:54:WARNING:WU00:FS00:Failed to get ID from 'assign4.stanford.edu:80': 10002: Received short response, expected 8 bytes, got 0
16:34:54:ERROR:WU00:FS00:Exception: Could not get an assignment ID
16:34:54:WU00:FS00:Connecting to assign3.stanford.edu:8080
16:38:26:WARNING:WU00:FS00:Failed to get ID from 'assign3.stanford.edu:8080': 10002: Received short response, expected 8 bytes, got 0
16:38:26:WU00:FS00:Connecting to assign4.stanford.edu:80
16:41:58:WARNING:WU00:FS00:Failed to get ID from 'assign4.stanford.edu:80': 10002: Received short response, expected 8 bytes, got 0
16:41:58:ERROR:WU00:FS00:Exception: Could not get an assignment ID
16:41:58:WU00:FS00:Connecting to assign3.stanford.edu:8080
16:45:32:WARNING:WU00:FS00:Failed to get ID from 'assign3.stanford.edu:8080': 10002: Received short response, expected 8 bytes, got 0
16:45:32:WU00:FS00:Connecting to assign4.stanford.edu:80
16:49:06:WARNING:WU00:FS00:Failed to get ID from 'assign4.stanford.edu:80': 10002: Received short response, expected 8 bytes, got 0
16:49:06:ERROR:WU00:FS00:Exception: Could not get an assignment ID
16:49:07:WU00:FS00:Connecting to assign3.stanford.edu:8080
16:52:40:WARNING:WU00:FS00:Failed to get ID from 'assign3.stanford.edu:8080': 10002: Received short response, expected 8 bytes, got 0
16:52:40:WU00:FS00:Connecting to assign4.stanford.edu:80
16:56:14:WARNING:WU00:FS00:Failed to get ID from 'assign4.stanford.edu:80': 10002: Received short response, expected 8 bytes, got 0
16:56:14:ERROR:WU00:FS00:Exception: Could not get an assignment ID
16:56:14:WU00:FS00:Connecting to assign3.stanford.edu:8080
16:59:48:WARNING:WU00:FS00:Failed to get ID from 'assign3.stanford.edu:8080': 10002: Received short response, expected 8 bytes, got 0
16:59:48:WU00:FS00:Connecting to assign4.stanford.edu:80
17:03:21:WARNING:WU00:FS00:Failed to get ID from 'assign4.stanford.edu:80': 10002: Received short response, expected 8 bytes, got 0
17:03:21:ERROR:WU00:FS00:Exception: Could not get an assignment ID
17:03:21:WU00:FS00:Connecting to assign3.stanford.edu:8080
17:06:57:WARNING:WU00:FS00:Failed to get ID from 'assign3.stanford.edu:8080': 10002: Received short response, expected 8 bytes, got 0
17:06:57:WU00:FS00:Connecting to assign4.stanford.edu:80
17:10:30:WARNING:WU00:FS00:Failed to get ID from 'assign4.stanford.edu:80': 10002: Received short response, expected 8 bytes, got 0
17:10:30:ERROR:WU00:FS00:Exception: Could not get an assignment ID
17:10:30:WU00:FS00:Connecting to assign3.stanford.edu:8080
17:14:03:WARNING:WU00:FS00:Failed to get ID from 'assign3.stanford.edu:8080': 10002: Received short response, expected 8 bytes, got 0
17:14:03:WU00:FS00:Connecting to assign4.stanford.edu:80


Re: (Client connects) but WU does not download

Posted: Fri Sep 06, 2013 5:49 pm
by Joe_H
It looks like anti-malware software or your firewall is blocking access from non-browsers to http type connections. You would get some of the same results if you need to use a proxy server and don't have that configured.

You mentioned you don't have access to these settings, that implies the system is not your own. If that is the case, do you have permission of the owner to run F@H on the system? The EULA for F@H does require you have that permission before using it on someone else's machine. If this is your machine, what anti-malware software or firewall are you using? Does your ISP require use of a proxy server, we can help with getting the settings entered correctly.

Re: (Client connects) but WU does not download

Posted: Fri Sep 06, 2013 6:24 pm
by Napoleon
gcallantii wrote:

Code: Select all

16:27:54:       Config: C:/Documents and Settings/gcallant/Application
16:27:54:               Data/FAHClient/config.xml
---
16:27:54:          CWD: C:/WINDOWS/system32
The work directory (CWD) looks pretty strange, too. I mean, config.xml seems to be in a sensible place, then suddenly... :e?:

Re: (Client connects) but WU does not download

Posted: Fri Sep 06, 2013 6:31 pm
by gcallantii
Yes it is my system, but my ISP blocks port 80, and 8080 (verified with a port scan). No, my ISP does not require the use of a proxy server, but certain ports on my system are blocked (apparently). I didn't realize that a browser could connect even if port 80 was closed (apparently mine is). But port 443 is open. Is there a way to force F@H to connect through port 443, or other open port, or a way to redirect traffic through that port to port 80? I have used proxies in the past, but mainly web based proxies, and tor. I have never been successful with setting up software to take advantage of a proxy (or been able to configure a proxy to redirect port traffic). Any information on that topic would be much appreciated however.

Re: (Client connects) but WU does not download

Posted: Fri Sep 06, 2013 6:33 pm
by gcallantii
Napoleon wrote:
gcallantii wrote:

Code: Select all

16:27:54:       Config: C:/Documents and Settings/gcallant/Application
16:27:54:               Data/FAHClient/config.xml
---
16:27:54:          CWD: C:/WINDOWS/system32
The work directory (CWD) looks pretty strange, too. I mean, config.xml seems to be in a sensible place, then suddenly... :e?:
I have this running as a service (which is why you see it in system32), because I do not have a compatible GPU, and want this to run every time my computer is started.
Would running it is a service impact whether or not it can download properly?

Re: (Client connects) but WU does not download

Posted: Fri Sep 06, 2013 6:40 pm
by 7im
Running as a service has no impact on downloads. The fahclient behaves like a web browser, so if you get OKs from those pages, you should be able to fold.

Check your browser settings. Any proxy or special port settings used there?

Since port 80 is always open for web browsing, fah does not allow the port to be configured otherwise.

Re: (Client connects) but WU does not download

Posted: Fri Sep 06, 2013 7:12 pm
by Joe_H
Port 80 can be firewalled, and depending on what the packet contains not be "open" to a port scan. Other data can pass. You may have to contact your ISP to determine how to connect when not using a browser.

Re: (Client connects) but WU does not download

Posted: Fri Sep 06, 2013 8:05 pm
by gcallantii
Yeah that's so weird. To add insult to mystery, I can use Chrome to connect to assign3.stanford.edu etc... but if I use IE, it won't load the page. There are of course no special settings in Chrome, and no proxy setup in Internet options, so I don't know.

Re: (Client connects) but WU does not download

Posted: Fri Sep 06, 2013 10:11 pm
by bruce
One guess is that your ISP is modifying the connections that your browser is using, either when you install the browser or when you install the pre-packaged software that they recommend but a much more likely scenario is that you have installed anti-virus or other security software that is blocking specific software from making an outgoing connection. It's often known as anti-spyware software.

Temporarily disable your security suite. Does that permit FAH (or IE) to connect on port 80?

Re: (Client connects) but WU does not download

Posted: Sat Sep 07, 2013 2:48 pm
by Jesse_V
I'm surprised that they blocked port 80, as that's the main http port. FAH adopted that port because it was the easiest to get through and was rarely blocked.

Here at USU, the campus firewall by default blocks all incoming connections but allows outbound and established connections through. This doesn't interfere with browsing, FAH, or most everyday Internet activities though. I too would suspect your security suite or the network/firewall settings on your end.

Re: (Client connects) but WU does not download

Posted: Sat Sep 07, 2013 5:39 pm
by bruce
Jesse_V wrote:I'm surprised that they blocked port 80, as that's the main http port. FAH adopted that port because it was the easiest to get through and was rarely blocked.

Here at USU, the campus firewall by default blocks all incoming connections but allows outbound and established connections through. This doesn't interfere with browsing, FAH, or most everyday Internet activities though. I too would suspect your security suite or the network/firewall settings on your end.
Suppose somebody evil wants to install malware on your computer to capture your passwords or your credit card numbers or whatever. One way to create such a program would be to make it act like a browser which "phones home" when it discovers what it's looking for but it does it surreptitiously. Your security suite can stop this sort of activity by blocking all outgoing connections from unknown programs, and requiring you to specifically authorize those which you know are safe -- hence IE and FAH can be blocked until you grant them an exception (unless they happen to meet some predefined policy of your security software).

What security software are you using?

Re: (Client connects) but WU does not download

Posted: Sat Sep 07, 2013 8:07 pm
by gcallantii
No, that makes sense, I guess I just don't understand how my "security suite" can recognize some types of software, but not others... as in my example with Chrome working, but not IE working. Which doesn't make sense. It is TrendMicro. Also, IE is the default install browser. I installed Chrome on later (because we all know IE sucks, and is SOOO vulnerable- sorry Microsoft :( ). Also, I use different programs all the time to connect to my servers and don't have problems even when using proprietary software that connects flawlessly to LDAP servers, but again... doesn't let IE connect...?? I've also tried using TOR and even tried using the relay bridge route... to bypass the known blocked network IPs, which seems to bypass the 80 port and go straight for the 443 which is available, but it seems it gets stuck at 10%, and wonder if it is also having problems with stupid TrendMicro.... I'm gonna' try disabling that see if anything works.

Re: (Client connects) but WU does not download

Posted: Sat Sep 07, 2013 8:10 pm
by gcallantii
Just to make it easier, there's not possibly some code I can edit in the config file (or god forbid in a .dll file.. *sigh*) to make outbound and inbound connections occur on the client on port 443?

Re: (Client connects) but WU does not download

Posted: Sat Sep 07, 2013 8:58 pm
by Jesse_V
Try disabling TrendMicro temporarily and see if that changes anything. Try one thing at a time, and that may help isolate the problem.

Re: (Client connects) but WU does not download

Posted: Sat Sep 07, 2013 11:14 pm
by bruce
gcallantii wrote:Just to make it easier, there's not possibly some code I can edit in the config file (or god forbid in a .dll file.. *sigh*) to make outbound and inbound connections occur on the client on port 443?
No. The client is not configurable and the Stanford Servers would not accept requests that try to connect to their port 443 anyway.

You have two choices. A) Confirm that it's TrendMicro that's blocking the connection and reconfigure TrendMicro so that it permits FAH to use ports 80 and/or 8080. and (B) set up a proxy which redirects FAH's connection attempts so that it can sneak around the protection that TrendMicro is recommending.

Choice A is the best, by far.

TrendMicro technical support should be able to help you if you don't figure it out for yourself.