I've just started playing with Coda, and I'm seeing a problem with my
  portable computer running NetBSD:

I've been using coda since 1997 or 1998, on FreeBSD and NetBSD.
My notebook has run NetBSD for about 1.5 years (1.6ish and now
current), and I move it around all the time and coda works fine.

I have a venus process started on boot, and then I take interfaces up
and down with different addresses, and venus deals fine with the
change in IP address.

As Jan points out, venus will get a new connection to the server and
have to revalidate cache entries.  This is only annoying over dialup,
and a bit better revalidation control (between per-file and
per-volume, with some sort of subtree hashes) would be nice, but the
current situation is not broken.  It would be cool to have a Host
Identity Payload that the server can use to bind the two client
sessions together to migrate callbacks, but that isn't implemented.
Perhaps as part of IPv6 support.

I bring interfaces down (deleting addresses first) before suspending,
and then bring them up at the new place.  I tend not to have both
wired and wireless up at the same time.

I have also patched dhclient to catch SIGTERM and remove the
addresses.

I have not read the RPC2 code well enough to know exactly what it
does, but running fstat/netstat shows a socket with local
address*.65xxx and foreign address *.*.  So I bet it just calls
sendto().  This should just use the default route.

  Coda uses UDP, I was guessing that this would be OK.  It's not...

Do you still have an interface up with an address that doesn't work
(e.g., address on wired net with cable not plugged in)?
If you 'ifconfig down' non-functional interfaces, is venus then able
to connect to the server?

  Another, semi-related problem is that our wireless network does NAT,
  and because of this, the UDP port that Venus listens at can change, as
  seen from the outside, if the machine is quiescent for a while.  As
  far as I can tell, this introduces a bit of flakiness in the
  connection to the Coda server, but nothing really too bad.

Yes, it causes a minor problem, which is that the server has recorded
leases for your machine, and if someone else tries to access the files
(write, if you have a read lease, or at all if you have a rw lease),
the server will do callbacks that time out, and the other user will
stall for some time (30s?).  Then the callbacks get broken as an error
condition, and things proceed.  This gets you into the disconnected
situation where you don't have a consistency guarantee, but this
happens anyway with disconnected operation so it isn't "broken" per
se.

-- 
        Greg Troxel <gdt_at_ir.bbn.com>

This is wrong (multiprocessing hazard), but it works all the time for me.
netbsd dhclient fix to remove addresses at exit:

Index: dist/dhcp/client/dhclient.c
===================================================================
RCS file: /QUIST-CVS/netbsd/src/dist/dhcp/client/dhclient.c,v
retrieving revision 1.1.1.4
retrieving revision 1.3
diff -u -r1.1.1.4 -r1.3
--- dist/dhcp/client/dhclient.c	2 Dec 2003 15:14:22 -0000	1.1.1.4
+++ dist/dhcp/client/dhclient.c	2 Dec 2003 17:20:39 -0000	1.3
@@ -87,6 +87,7 @@
 
 static void usage PROTO ((void));
 
+static void catch_sigterm(int x);
 void do_release(struct client_state *);
 
 int main (argc, argv, envp)
@@ -272,6 +273,9 @@
 	} else
 		log_perror = 0;
 
+	/* Set up SIGTERM handler to clean up state. */
+	signal(SIGTERM, &catch_sigterm);
+
 	/* If we're given a relay agent address to insert, for testing
 	   purposes, figure out what it is. */
 	if (relay) {
@@ -2931,6 +2935,12 @@
 static void shutdown_exit (void *foo)
 {
 	exit (0);
+}
+
+static void catch_sigterm(int x)
+{
+	/* undo resolv.conf, release leases, unconfigure interface */
+	dhcp_set_control_state(0 /* XXX unused */, server_shutdown);
 }
 
 isc_result_t dhcp_set_control_state (control_object_state_t oldstate,