[sclug] Distributed computing

[Jonathan H N Chin]

Tony Sumner <whittycat at ntlworld.com> wrote:
> On Mon, Jan 20, 2003 at 12:20:27PM +0000, Jonathan H N Chin wrote:
> 
> 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) [...]

As I said in my footnote, the port on the client is not relevant
unless the server is attempting to initiate a connection.
Considering the proliferation of firewalls these days, it seems
unlikely that someone would design a protocol where the client
must listen for connections.


> 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

I thought snort was a NIDS. It is unlikely that it would be
triggered by replies to your own outgoing packets.

I quite like ngrep.
A line like this would show the payloads in a fairly readable format:

    ngrep -xq . 'host mymachine and host remotemachine and port 80'

With tcpdump, more noisy output would be given by something like:

    tcpdump -xX 'host mymachine and host remote machine and port 80'


> (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. 

Is each preceded by corresponding traffic from that port to the
remote port 80?


> 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

How do you know it isn't reaching the program?
If you think it is reaching your machine and is not being blocked by
netfilter, then it is likely that the client is discarding it.


> 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

I design my filtering to block everything by default, and then
allow exceptions.


> > 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?

Perhaps I should have written: "it seems likely that the clients are
using an http-like protocol for communicating with the server."
I suspect these packets you see from remote port 80 are just replies
to your original connection.


> They arrive at the kernel log but they don't get to the client. I had a

Are you sure? What does strace show?
Attach to or run the client under something like:

	strace -f -ff -o tracelog -e trace=network -s 4096 client


A brief scan of the free-dc forum indicates that some ntl users
have been bitten by its use of a transparent web proxy.
You appear to be an ntl user.



-jonathan

-- 
Jonathan H N Chin, 1 dan | deputy computer | Newton Institute, Cambridge, UK
<jc254 at newton.cam.ac.uk> | systems mangler | tel/fax: +44 1223 335986/330508

                "respondeo etsi mutabor" --Rosenstock-Huessy