On Thu, Apr 15, 2004 at 09:00:17PM +0200, Tom Ivar Helbekkmo wrote:
> Jan Harkes <jaharkes_at_cs.cmu.edu> writes:
> > 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.

Ehh, cfs cs simply tells the client to send a simple probe call to the
server. The way the packets are sent should be fairly simplistic, we
locally bind the socket to the INADDR_ANY address and send a UDP packet
to the IP address of the server.

The kernel should just route this out of the right interface and set the
source address of the packet with the correct address for receiving the
responses. My guess is that it would just follow whatever the default
route has been set to.

Could you check with tcpdump if there are any packets going to port 2432
on any of the available interfaces, and of course if any responses are
coming back from port 2432.

Does the ip-address of the server change depending on whether you are
connected over wireless or with the 100Base-T cable?

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

Well, that ofcourse makes everything start from scratch. So venus will
redo realm/hostname lookups, and requery the rootvolume/volume location
information.

> 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.  :-)

client			server

    clog	->	auth2
    */udp   		370/udp

    venus		codasrv
    */udp	<>	2432/udp

Some firewalls can set up a fixed mapping between a client and a server
if both port numbers are fixed, so the local venus socket can be set to
an arbitrary fixed portnumber (venus.conf option masquerade_port=XXX).

For the rest, we don't use any of the assigned TCP ports.

> rpc2portmap	369/udp			# Coda portmapper

This one is used by updateclnt/updatesrv.

> venus		2430/udp		# Venus callback/wbc interface
> venus-se	2431/udp		# udp sftp side effect
> codasrv-se	2433/udp		# udp sftp side effect

In general, firewalls made it pretty much impossible to run the bulk
data side-effects (SFTP) over a separate 2431/2433 port-pair. So that
traffic was completely merged int the existing RPC2 data 'stream'. Also
the masquerading part of many firewalls made relying on a single fixed
port for the client impossible, so that one can now be anything.

Jan