Coda File System

Re: 1 Server + 1 Client = Big Headache

From: Jan Harkes <>
Date: Fri, 25 Feb 2005 13:12:27 -0500
On Thu, Feb 24, 2005 at 03:00:11PM -0800, redirecting decoy wrote:
> I have a new problem. Well, not really a new problem, just newly noticed.
> I can't get my client to connect to my server.

Let's see if I got this right

Client (M2)           Server (M1)                      TestServer (M3)
     |eth0         eth0|      |eth1                  eth1|       |eth0 -- -- -->

And you used the ipaddress= option to bind the Coda server socket to on M1.

The Linux kernel internally forwards the packet between eth0 and eth1.
However from the logs it looks like that when we try to send the reply
from to an address, the kernel doesn't use as the source address. I thought that by explicitly
binding to some address that it should actually use that address as the

In any case, that first message from the client to the server is an
INIT1 packet, the server then responds with INIT2. Because this is
probably a connection to do the initial query we should not see the
additional INIT3/INIT4 authentication handshake. So the connection
would be assumed up as soon as we get the reply.

I'm not sure what the client sends next, might be a NAK to tell to butt out of the conversation with

Now when you changed to ipaddress=, things seem to work at
first, the server gets our request, and we see the replies. The problem
in this case is probably that when we get to the step where we ask for
when we ask for the volume location we get ''. Now we try
to bind to that address, and we end up with the same problem that
'' is trying to interfere with the handshake with ''.

I don't think this is necessarily iptables related, but it could be that
once the packet mangling modules are loaded in the kernel it always
rewrites the packets as they go out. Also that masquerade rule does
match the packets from the client to the Coda server, but even in the
worst case it should really only mangle the source address in such a way
that the server thinks the packets are coming from a client running
locally and mangle the destination address in the responses to make it
look like the server did not actually send the replies to itself.

In any case we should be able to fix this specific problem with an
additional iptables rule.

iptables -t nat -A POSTROUTING \ # mangle any outgoing packets,
	-i eth0 -s \	 # sent by us on eth0,
	-p udp --sport 2432 \    # which are coming from codasrv/udp,
	-j SNAT --to-source # in such a way that it looks like
					   # they came from

Bind the server to, and let it think that it's name
matches that 'public address' so that the volume location responses will
also use as the server's address.

Received on 2005-02-25 13:14:16