6.23SMP client cannot upload results to any server [port 80]

[GraceCourt]

Bruce, I previously posted as follows to the "Couldn't send HTTP request to server" topic at viewtopic.php?f=50&t=13682 but I see that you have now locked that topic.

I'm beginning to suspect that there might be an issue with this client... I see that the original poster's issue doesn't seem to be resolved, and I'm having exactly the same problem:
[22:02:43] + Attempting to send results [April 17 22:02:43 UTC]
[22:02:43] - Couldn't send HTTP request to server
[22:02:43] + Could not connect to Work Server (results)
[22:02:43] (171.67.108.25:8080)
[22:02:43] + Retrying using alternative port
[22:02:43] - Couldn't send HTTP request to server
[22:02:43] + Could not connect to Work Server (results)
[22:02:43] (171.67.108.25:80)
[22:02:43] Could not transmit unit 03 to Collection server; keeping in queue.

The difference is that I'm running clients on 8 identical PCs on two different networks. They are dual core processors.... when I set them up with two 6.23 Windows console clients in two separate directories, no problems... they run at 100% processor utilisation, download work units and upload results as expected. But if I install a single SMP client, it downloads work units, runs at 100%, and ... never uploads the results. All eight machines are the same. No firewall on any of the PCs (hardware firewall on the subnet). I've tried accessing the results servers with a browser, and I get the expected "OK" on port 80 and on port 8080. It's driving me mad.

And on one machine I uninstalled the SMP client and re-installed the original clients... runs perfectly.

Extract from the log on one of the SMP versions shown... the results files are building up and the stats servers are showing that none of these machines has uploaded results for over a week (i.e. since the SMP clients were installed). They are all attempting upload and failing.

Broken client?

PS -Because of the IE settings issue mentioned above, some of these PCs are set to IE autodetect setting, the rest otherwise. No difference.

You responded: "Server 171.67.108.25 is a collection server, so it's just a backup for some other server. Please identify the other server and if you haven't already done so, look for a topic on that server in the forum Issues with a specific server Before you post there, read the topic on "Do this first"". But the issue is not with a specific server (so I didn't post there), it's with the 6.23 SMP client, as none of the eight machines can upload to either the work unit or collection servers using this client (only) as follows:

[21:06:01] - Couldn't send HTTP request to server
[21:06:01] + Could not connect to Work Server (results)
[21:06:01] (130.237.232.140:80)

[21:06:23] - Couldn't send HTTP request to server
[21:06:23] + Could not connect to Work Server (results)
[21:06:23] (130.237.162.125:80)

[21:06:25] - Couldn't send HTTP request to server
[21:06:25] + Could not connect to Work Server (results)
[21:06:25] (171.64.65.54:80)

[21:06:25] - Couldn't send HTTP request to server
[21:06:25] + Could not connect to Work Server (results)
[21:06:25] (171.67.108.25:80)

Yet when I remove the SMP client and replace it with one or two copies of the non-SMP client, these run without any problems whatsoever - I've left two non-SMP clients on one of the eight for a fortnight, it's working fine, the other seven machines haven't uploaded anything at all over those two weeks, but they keep downloading new work units.

I've set verbosity to 9 on one of them and will post the results here in a few days, but if anyone can explain why only the 6.23 SMP client fails on these machines, it will help to preserve my sanity.

[P5-133XL]

Since the IE settings are use autodetect settings and that is only useful if there is a proxy server somewhere in the line, are you using a proxy server?

[bruce]

All I'm really saying is that you need to identify your problems with servers 171.64.65.54 and 130.237.232.140 rather than with the collection servers. My locking the thread didn't mean your problem wasn't important -- it's just that we can't fix the collection servers right now.

please include a larger segment of FAHlog showing the message prior to "Couldn't send HTTP...."

Are you able to open http://130.237.232.140 and http://171.64.65.54 in your browser?

[GraceCourt]

Since the IE settings are use autodetect settings and that is only useful if there is a proxy server somewhere in the line, are you using a proxy server?

No, there's no proxy server. I should have explained that I started off with a "no proxy server" setting on all of them - the only reason for changing those settings on some of the machines was to be scientific about fault-finding why there was a problem.

please include a larger segment of FAHlog showing the message prior to "Couldn't send HTTP...."

[15:04:47] Unit 7's deadline (April 25 14:56) has passed.
[15:04:59] - Autosending finished units... [April 25 15:04:59 UTC]
[15:04:59] Trying to send all finished work units
[15:04:59] Project: 6023 (Run 0, Clone 78, Gen 126)

[15:04:59] + Attempting to send results [April 25 15:04:59 UTC]
[15:04:59] - Reading file work/wuresults_09.dat from core
[15:04:59] CoreStatus = 65 (101)
[15:04:59] Core internal error: SPECIAL_EXIT
[15:04:59] (Read 20416856 bytes from disk)
[15:04:59] Connecting to http://171.64.65.54:8080/
[15:04:59] - Couldn't send HTTP request to server
[15:04:59] + Could not connect to Work Server (results)
[15:04:59] (171.64.65.54:8080)
[15:04:59] + Retrying using alternative port
[15:04:59] Connecting to http://171.64.65.54:80/
[15:05:01] - Couldn't send HTTP request to server
[15:05:01] + Could not connect to Work Server (results)
[15:05:01] (171.64.65.54:80)
[15:05:01] - Error: Could not transmit unit 09 (completed April 24) to work server.
[15:05:01] - 10 failed uploads of this unit.

[15:05:01] + Attempting to send results [April 25 15:05:01 UTC]
[15:05:01] - Reading file work/wuresults_09.dat from core
[15:05:01] (Read 20416856 bytes from disk)
[15:05:01] Connecting to http://171.67.108.25:8080/
[15:05:01] - Couldn't send HTTP request to server
[15:05:01] + Could not connect to Work Server (results)
[15:05:01] (171.67.108.25:8080)
[15:05:01] + Retrying using alternative port
[15:05:01] Connecting to http://171.67.108.25:80/
[15:05:01] - Couldn't send HTTP request to server
[15:05:01] + Could not connect to Work Server (results)
[15:05:01] (171.67.108.25:80)
[15:05:01] Could not transmit unit 09 to Collection server; keeping in queue.
[15:05:01] + Sent 0 of 1 completed units to the server
[15:05:01] - Autosend completed

Are you able to open http://130.237.232.140 and http://171.64.65.54 in your browser?

The former gives the expected "OK" but I can't connect to the latter at present on any machine.

[toTOW]

And what happen if you open http://130.237.232.140:8080/ and http://171.64.65.54:8080/ in your browser ?

[GraceCourt]

And what happen if you open http://130.237.232.140:8080/ and http://171.64.65.54:8080/ in your browser ?

Both give the expected OK.

There is a software firewall installed on these machines but not only are they effectively disabled by allowing all outbound requests, they also log the successful connections with the FAH servers - successful as far as the IP stack is concerned anyway. From one of the machines that downloads new work packages but hasn't uploaded for weeks...
05:02:08 [email protected] OUT TCP 171.67.108.25 HTTP Allow all traffic
05:02:08 [email protected] OUT TCP 171.67.108.25 PROXY:8080 Allow all traffic
05:02:07 [email protected] OUT TCP 171.64.65.54 HTTP Allow all traffic
05:02:07 [email protected] OUT TCP 171.64.65.54 PROXY:8080 Allow all traffic
05:02:06 [email protected] OUT TCP 171.67.108.25 HTTP Allow all traffic
05:02:06 [email protected] OUT TCP 171.67.108.25 PROXY:8080 Allow all traffic
05:02:06 [email protected] OUT TCP 171.64.65.54 HTTP Allow all traffic
05:02:06 [email protected] OUT TCP 171.64.65.54 PROXY:8080 Allow all traffic

And, as already stated, all of these machines upload regularly as expected when installed with two non-SMP clients. Nothing else has been changed - just the FAH client version.

[GraceCourt]

And, as already stated, all of these machines upload regularly as expected when installed with two non-SMP clients. Nothing else has been changed - just the FAH client version.

Well, faced with SMP clients that don't upload any results, and non-SMP clients that upload results with no problems whatsoever, I've finally accepted the inevitable and taken all of the SMP clients off these PCs. The non-SMP clients have been restored (2 on each machine to get 100% processor utilisation) and the results are flowing again.

Maybe if anyone figures out the problem with the 6.23 SMP client, they could post the solution here - even if it's just to satisfy my curiosity!

[7im]

Why v6.23 SMP client, and not the newest v6.29 version?

[bruce]

Your firewall settings look reasonable but you appear to be the only person reporting this sort of problem so I'm not sure anybody can help you.

I divide firewalls into two categories: Ones which protect from external intrusion and ones which also protect against outgoing problems such as spyware. From time to time, people have difficulties configuring the anti-spyware type of firewall but FAH never seems to have a problem with the simpler firewall.

In my experience, a good anti-spyware firewall may permit [email protected] to make outgoing connections, but if the checksum of [email protected] changes, then it's no longer the same program so it no longer has permission to make connections. You might try removing those settings and creating the same ones again, but that's just a guess. (This would also be a good chance to upgrade to the latest version, as 7im suggests, but that's not important as long as you intend to run classic clients.)

If that doesn't work, consider the following approach:
First, do you suspect that your computer is already infected with spyware? If not, try the following:
Disconnect from the internet.
Either disable this firewall and enable a simple one (such as the one supplied by Microsoft).
Reconnect to the internet and do NOT do any browsing or other risky behavior that might allow spyware to infect your computer; Start ONLY FAH and see if it uploads.
Reverse these steps to restore your normal protections.

At least then you'll know if you've missed a firewall setting that has been blocking FAH from uploading.