Failed uploads of all Wu's from XP Box

[dschief]

Problem is back & worse!

Wu's are completing, with no Error's indicated. New Wu's are downloading & running.

Xp box now has 2 stuck with same msg. as before

Code: Select all

19:26:16:WARNING:WU03:FS01:Exception: Failed to send results to work server: 10002: Received short response, expected 512 bytes, got 0
19:26:39:WU00:FS02:Upload 10.00%
19:26:39:WARNING:WU00:FS02:Exception: Failed to send results to work server: 10002: Received short response, expected 512 bytes, got 0

Have checked firewall settings Fahclient is checked as a permitted program

SLP_Port (427)_TCP
SLP_port (427)_ UDP

are enabled.

just left the Wiki Page, this error Msg is FIRST on the list of COMMON V 7 error's! Somebody must have a clue as to what it is related to.

all of the failed uploads are targeting 140.163.4.234:8080

another box uploaded fine to 171.64.65.92:8080

Have run hundreds of wu's through this box with No problems, nothing changed in settings

This is driving me nuts, What else can I check on my end?

Update: Clicking on stuck Wu's shows 140.163.4.234 as Work server, under that it shows Collection Server as 0.0.0.0 which seems hinky

other wu;s show what seems to be a valid IP for Collection

[7im]

A clue? Maybe. But as you read in the WIKI, the list of common V7 errors was only just that. The start of a list. No answers provided.

You might try a Forum Search search.php?keywords=expected+512+bytes& ... mit=Search to see what others have found.

And not every work server has a collection server, so 0.0.0.0 is not as hinky as it looks.

[bruce]

Server 140.163.4.234 seems to be uploading and downloading WUs as recently as 18:40 PDT.

I can't think of any reason why WinXP would fail but others would not, but we do have to consider that possibility. It also might be a security setting in your router or proxy or firewall.

Are these the first WUs you've done from that server?

[dschief]

1. 30+ Wu's have made it upstream in the past 4 days, Same router/Modem.

2. the xp box had a good upload to 171.64.65.84

as far as I can see, every wu going to 140.163.4.234 fails: XP Box has one finishing in @ 15:00 min for 171.64.65.84. one for 140.163.4.234 in @ 2 hrs.

will post outcome

9114 (16,8,16 ) good upload to 171.64.65.84 at 02:37:28

For what it's worth, Iran tracert 140.163.4.234 & It timed out after 11 hops at 74.8.57.6

tracert to 171.64.65.84 the last good upload from the XP box found vspg12.stanford.edu in 9 hops

[Joe_H]

Can you access http://140.163.4.234:8080/ in a browser window? You should get a 401 HTTP UNAUTHORIZED message, but that does indicate a connection can potentially be made by the client. As best as I can tell this server accepts on port 8080, not port 80.

[dschief]

Link does not work, keep getting Connection Reset msg.

I did find that the IP is in reality Memorial Sloan-Kettering Cancer Center in New York.

Is it possible that I may have to add 140.163.4.234 as an Exception to Xp's Firewall, and having Fahclient is not good enough,
But then if that is a known quantity, it should have come up by now

[bruce]

Mine times out after 13 hops. It doesn't respond to pings either but that desn't necessarily stop it from accepting http: connections from the client.

I think I remember that they have different (increased) security at the site 140.163.0.0/16 compared to what Stanford uses.

The next upstream neighbor that DOES respond to my tracert is 74.8.57.6 which is apparently Sloan-Kettering ISP (outside their internal network). There certainly must be a few routers between the ISP and the machine that runs the FAH Work Server. KyleB is not actually in NY but nearby.

Search the forum for Sloan Kettering (no dash) and you'll find a number of similar reports, iincluding a note from kyleb:
viewtopic.php?f=18&t=26661&p=271741#p267924

[dschief]

The last wu' finished and Failed , now have three stuck

10475 (0,282,78 )

10476 (0,386,83 )

10477 (1,59,33)

Do not know if it matters, but while reading through one of the Threads there was an issue about the Server jumping from GPU to Classic.

Currently it is shown as Classic, Since these are all GPU Wu's could the server be stone walling them as an unexpected type?

[bruce]

My Linux box just uploaded to that server.

Code: Select all

20:53:08:WU01:FS01:0x18:Completed 5000000 out of 5000000 steps (100%)
20:53:15:WU01:FS01:0x18:Saving result file logfile_01.txt
20:53:15:WU01:FS01:0x18:Saving result file checkpointState.xml
20:53:17:WU01:FS01:0x18:Saving result file checkpt.crc
20:53:17:WU01:FS01:0x18:Saving result file log.txt
20:53:17:WU01:FS01:0x18:Saving result file positions.xtc
20:53:19:WU01:FS01:0x18:Folding@home Core Shutdown: FINISHED_UNIT
20:53:19:WU01:FS01:FahCore returned: FINISHED_UNIT (100 = 0x64)
20:53:19:WU01:FS01:Sending unit results: id:01 state:SEND error:NO_ERROR project:10475 run:0 clone:234 gen:87 core:0x18 unit:0x00000082538b3dba541056bc6fbaf4ce
20:53:19:WU01:FS01:Uploading 6.25MiB to 140.163.4.234
20:53:19:WU01:FS01:Connecting to 140.163.4.234:8080
20:55:37:WU01:FS01:Upload complete
20:55:37:WU01:FS01:Server responded WORK_ACK (400)
20:55:37:WU01:FS01:Final credit estimate, 20715.00 points
20:55:37:WU01:FS01:Cleaning up

So did Windows 7

Code: Select all

23:16:22:WU01:FS01:0x18:Completed 5000000 out of 5000000 steps (100%)
23:16:48:WU01:FS01:0x18:Saving result file logfile_01.txt
23:16:48:WU01:FS01:0x18:Saving result file checkpointState.xml
23:16:50:WU01:FS01:0x18:Saving result file checkpt.crc
23:16:50:WU01:FS01:0x18:Saving result file log.txt
23:16:50:WU01:FS01:0x18:Saving result file positions.xtc
23:16:52:WU01:FS01:0x18:Folding@home Core Shutdown: FINISHED_UNIT
23:16:52:WU01:FS01:FahCore returned: FINISHED_UNIT (100 = 0x64)
23:16:52:WU01:FS01:Sending unit results: id:01 state:SEND error:NO_ERROR project:10476 run:0 clone:4 gen:217 core:0x18 unit:0x0000011e538b3dba53f3805d4bf071e7
23:16:52:WU01:FS01:Uploading 6.12MiB to 140.163.4.234
23:16:52:WU01:FS01:Connecting to 140.163.4.234:8080
23:18:56:WU01:FS01:Upload complete
23:18:56:WU01:FS01:Server responded WORK_ACK (400)
23:18:56:WU01:FS01:Final credit estimate, 34288.00 points
23:18:56:WU01:FS01:Cleaning up

How about trying to migrate that FAH data directory to one of your VIsta or WIn7 machines and see if they will upload from there. Do you know how to sneakernet?

[Joe_H]

Link does not work, keep getting Connection Reset msg.

I did find that the IP is in reality Memorial Sloan-Kettering Cancer Center in New York.

Is it possible that I may have to add 140.163.4.234 as an Exception to Xp's Firewall, and having Fahclient is not good enough,
But then if that is a known quantity, it should have come up by now

If the link does not work in your browser, then something is blocking you from connecting to that server. You should get the access denied page I mentioned. I get that from my work PC and on my Mac at home. I did just now notice that I doubled up the "http://" in the address I posted and have fixed that.

As for the IP being at MSK, yes not all servers are at Stanford.

[davidcoton]

Is it possible that the server is using only port 8080, while your firewall (et al) are only allowing port 80? Long shot, but might be worth checking.

[bruce]

Yes, those servers use ONLY port 8080. That's why your browser gets "Unauthorized" from http://140.163.4.234:8080 but NOTHING from http://140.163.4.234:80. They really do have pretty tight security but under normal circumstances the FAH Client can get through.

(Good question about dschief XP box.)

[7im]

If you can download the WU from 8080, you should be able to upload it there as well.

[davidcoton]

If you can download the WU from 8080, you should be able to upload it there as well.

Why didn't I think of that? The remaining question is, what could cause failed uploads but not prevent downloads?

Have you tried a restart of the FAHClient (not just FAHControl)? It could be that uploads, having hit an error, are getting stuck with the known comms error recovery bug.

[dschief]

Have stopped, restarted Rebooted, run memtest, reinstalled driver! anything going to
140.163.4.234 = 100% failure.

Not an 8080 fire wall issue, this box has uploaded 2 wu's fine today

171.64.65.84:8080 & I just watched 171.64.65.93:8080 receive a wu in 3 min 07 sec

I now have 1 running destined for 140.163.4.235. Have about 19 hrs to figure this out before another one craps on me