Coda File System

Re: coda endian problems??

From: Jan Harkes <>
Date: Fri, 16 Jul 2004 22:09:10 -0400
On Fri, Jul 16, 2004 at 03:59:55PM -0500, Troy Benjegerdes wrote:
> kalmia had two aliased interfaces (, and 41), and was
> responding on the .40 address.. so I could see it locally, (cause it had
> the same mac), but those packets didn't get back to me.

Hmm, I don't really know about that. We do kind of rely on the kernel
routing outgoing packets to the right interface. However, volume
location is still only a single IP-address.

When a client first connects it basically asks the server where the root
volume is located. The server responds with an IPv4 address, which the
client then connects to. So if the server thinks it's address is the
(local/private?) address, clients might not be able to reach that
address from the outside.

We also don't bind to all interfaces like bind does, my interfaces go up
and down all the time because of switching between wired and wireless
LAN connections and keeping the interface specific bindings in sync
really makes for some ugly code. So we listen to the INADDR_ANY address
and use recvfrom to get the source address of the incoming packet. The
assumption is that if we send our reply to that address will get routed
back out of the same interface that the request came in from.

If it goes out the wrong interface, the other side will see this as an
unexpected reply (incorrect source address) and will drop the packet.

> I got burned by short hostnames ('kalmia' vs '') a
> couple of places as well.

Yeah, it works best when we consistenty use the fqdn, but most of the
scripts are still using only the hostname.

> What kind of issues would a IP-NAT box introduce? I think this may have
> been why my laptop (which is behind an openbsd IP-nat box at home) had
> some issues when untarring the kernel.. 

There shouldn't be all that many problems anymore. The RPC2 and SFTP
packets are going over the same port-pair. The client port no longer has
to be at a fixed address, the maximum packet size has been limited to
avoid IP fragmentation with a 1500 byte MTU and we send a keepalive ping
about once every 150 seconds as some NAT firewalls forget about the
redirection in about 3 minutes.

Now if your MTU is smaller than 1500 bytes there is IP fragmentation
and some firewalls actually drop everything but the first fragment
(defragmenting costs time and memory).

Received on 2004-07-16 22:14:08