Jan Harkes <jaharkes_at_cs.cmu.edu> writes:

> Ok... STOP IT!!! This thread is filled with so much speculation and
> misinformation that I don't even know where to start correcting.

Great!  :-)

> - Coda servers depend on having a fixed IP address (and port).
> - Coda clients don't have any such dependency, they can switch addresses
>   and ports, and in fact my laptop does this all the time.

OK, this is really interesting.

> However, the switch is not necessarily transparent. i.e. in many cases
> we in fact have to go through a disconnected state, simply to maintain
> the required consistency guarantee. It also depends on how the switch
> occurs on what the behaviour is. In some cases, we simply get an
> RPC2_NAK and can immediately rebind to the server. In other cases we
> actually get disconnected for a bit (i.e. new route might not yet be
> usable) and we switch to disconnected mode and will reconnect within the
> next 5-10 minutes when the automatic serverprobe discovers what we have
> a usable connection to the servers.

Hmm.  Do you do anything actively to make this happen?  If I just
change connection methods, which updates the addresses and routing
table, venus ceases to communicate with the Coda server.  I have not
been able to get it to continue without restarting it, in any way but
to reconnect to the same network it was started on.

> Run 'cfs cs' (cfs checkservers) instead of restarting venus. It will
> simply trigger a new serverprobe at that time instead of waiting for the
> automatic probe in the background.

For me, this does not work.  In my office, connected to the 100Mbps by
cable, and to the wireless network at the same time, with the default
route going out the cable, I have several times tried disconnecting
the cable, and changing the default route to the wireless interface.
My venus does not manage to reconnect to the server over radio, and if
I run "cfs cs", that command just hangs for a little while, and then
says that my server is still unreachable -- again and again.  In this
condition, I can run clog, and it actually authenticates me to the
server by radio, acquiring a new token, but venus still thinks there
is no connection to the server.  If I then stop and start venus, it
immediately works (but I have to get a new token, of course).

Oh, and I'm using version 6.0.5 under NetBSD/i386-current.

> First of all, typical NAT firewalls seem to forget about UDP
> 'connections' withing 3 minutes or so.

Ours drops them after 1 minute, so I've had to lower the keepalive
interval to 45 seconds.  And yes, the bloody thing does NAT.  The only
type of network equipment that's more frustrating than a firewall is a
firewall that does NAT.  :-(

> Secondly, a lot of firewalls are pretty dumb as far as fragmented
> packets are concerned.

That's interesting -- I hadn't thought of that.  I'll try adjusting
validateattrs down to 15, and see what happens.

Another thing, though: can you explain which ports the firewall needs
to allow traffic through, and in which directions?  Our security
people don't like the "well, you'd better open all of these all ways
just to be sure" approach.  :-)

Out of the following list, I've so far only noticed traffic from the
client to the server at 370/udp and 2432/udp, and back from the server
to the originating port on the client:

rpc2portmap	369/tcp
rpc2portmap	369/udp			# Coda portmapper
codaauth2	370/tcp
codaauth2	370/udp			# Coda authentication server

venus		2430/tcp		# codacon port
venus		2430/udp		# Venus callback/wbc interface
venus-se	2431/tcp		# tcp side effects
venus-se	2431/udp		# udp sftp side effect
codasrv		2432/tcp		# not used
codasrv		2432/udp		# server port
codasrv-se	2433/tcp		# tcp side effects
codasrv-se	2433/udp		# udp sftp side effect

-tih
-- 
Tom Ivar Helbekkmo, Senior System Administrator, EUnet Norway
www.eunet.no  T: +47-22092958 M: +47-93013940 F: +47-22092901