[sclug] Distributed computing

[Tony Sumner]

On Mon, Jan 20, 2003 at 12:20:27PM +0000, Jonathan H N Chin wrote:

> I shall assume that there is a central server somewhere that doles
> out jobs to participating clients and saves the results, rather than
> the system being properly distributed.

OK, I'll have to state the problem in more detail. I wanted to start
by settling the point about random ports first (which is explained in
the Assigned Number d/b) and then Alex suggested I grab ethereal. That
has taken me several hours so far -- everything depends on everything
else -- but I am close. This may tell me something or it may not; I
already have snort and tcpdump but I am not too hot on interpreting
what they say.

The way the program works is that I d/l a program from DIstributed Folding 
(DF) (binary) and run it. It first sends a command equivalent to
  GET http://www.distributedfolding.org/server.status to get the
server status and then does some work on folding proteins.  After a
few hours (or if you hit Q) it sends results to the server and
continues. 15999 people are happy with this (some of them running RH
8.0 too) but for me what happens is that I get a message 'Cannot get
server status', I do the work, send the results (they do get there)
and get a message 'You seem to have a problem with the network' and it
stops.  What I can't do is run it unattended as it should. snort
prints the packets originating from me that contain the results and
these are ok but does not record ANY packets originating from the
server. On the other hand tcpdump records packets like these

16:23:30.024362 206.248.62.8.80 > 80.5.144.178.1074: S [tcp sum ok]
1771487702:1771487702(0) ack 985653817 win 65160 <nop,nop,timestamp
9848413 10876945,nop,wscale 0,nop,nop,sackOK,mss 1460> (DF) (ttl 61,
id 3032, len 64)

which originate from the DF server port 80 and go to various ports >1023. 
Moreover when I added a line 

-A RH-Lokkit-0-50-INPUT -s 206.248.62.8 -j LOG --log-prefix IP

to iptables the kernel logs packets like

IN=eth0 OUT= MAC=00:40:f4:58:4a:50:00:05:9a:d6:b8:a8:08:00
SRC=206.248.62.8 DST=80.5.144.178 LEN=60 TOS=0x00 PREC=0x00 TTL=252
ID=17671 DF PROTO=TCP SPT=80 DPT=1026 WINDOW=34752 RES=0x00 ACK SYN
URGP=0

(the destination port is different cos this was done at a different time).
It goes on to try every dport from 1026 to 1037 and then gives up. 

Right. What I am trying to find out is why the server seems to be
sending me an acknowledgment but it does not reach the program. I
don't think that iptables is blocking it because 'service iptables
stop' doesn't make any difference and anyway the rules do not say
anything about ports between 1024 and 2048. I have no other security
stuff as far as I know. Somewhere I should see the result of the GET
call, ie the actual text of server.status which is (20.1.03)

118 112 114 5000 118 112 114
SERVER DOWN FOR MAINTENANCE, TRY AGAIN LATER
ftp.mshri.on.ca /pub/distribfold/download/patch/
bar.csh.rit.edu /~distribfold/
bar.csh.rit.edu /~distribfold/

(the server they are talking about here is 192.197.250.54 or deep.mshri.on.ca);
it has been down for the last few days.

> Given that you say "the source port is 80", it seems likely that the
> server is using an http-like protocol for communicating with clients.

What happens if the server sends TCP on port 80?

> You say that "packets arrive back but they seem to vanish".
> I don't understand what this means. 

They arrive at the kernel log but they don't get to the client. I had a
long conversation with Howard Feldman of DF and he suggested I acquire
a packet sniffer (so I got snort) and tell him what packets came from
the server. He couldn't understand why there weren't any.

I bet it is something really simple I have overlooked

Tony