I know, the official answer is, "Change the UDP timeouts on your NAT box." But of all the cool things my particular DSL modem/router allows me to configure, UDP timeouts isn't one of them. Besides, there ought to be a way to make this work in software.
In fact, in 2000 Matthew Fredette wrote his excellent natkeep-0.1, which watches your network and, upon seeing outbound UDP packets, it periodically sends identically addressed UDP packets with a ttl=1, so they die once they pass through your NAT box, but with the side effect of keeping your NAT UDP connection mappings alive, which makes AFS clients work from home. Yea!
Unfortunately, natkeep uses GNU threads and the pcap library (nothing against either of those per se) and is a little heavy handed. Making it work with current Linux technologies looks like a lot of work, too. (But don't let that stop you!)
Then I got to thinking, maybe I could hack the natkeep functionality directly into OpenAFS. [This is where you sigh and groan, okay.] Turns out there's a great place to put such a critter, too. As a sort of proof of evil concept, I duplicated a couple of lines in afs_CheckServerDaemon() like so:
--- afs_daemons.c-orig 2003-03-06 09:53:25.000000000 -0500
+++ afs_daemons.c 2003-09-26 16:21:02.000000000 -0400
@@ -75,6 +75,8 @@
now = osi_Time();
if (PROBE_INTERVAL + lastCheck <= now) {
afs_CheckServers(1, (struct cell *) 0); /* check down servers */
+ afs_Trace1(afs_iclSetp, CM_TRACE_PROBEUP, ICL_TYPE_INT32, 600);
+ afs_CheckServers(0, (struct cell *) 0); /* check the up servers too; -- tml */
lastCheck = now = osi_Time();
}
After setting PROBE_INTERVAL to 25 seconds via "fs checks -interval 25", this makes my client check the up servers as well as the down servers every 25 seconds, which keeps my NAT mappings fresh. It also hits my fileservers 20+ times as often, which is probably not a Good Thing. In fact, I would expect this technique to be about as popular among the OpenAFS keepers as the sys_call_table hack is with Alan Cox. Still, it's just a proof of concept. Of course I would _never_ run this sort of thing from home except as a test (wink wink)!
So, here's the question: would an afs_CheckServers()-like function that did a natkeep-like thing with a configurable ttl -- all optional and properly integrated into configure of course -- for the purposes of running OpenAFS clients from behind NAT boxes be welcome, or should I slither back to my evil dark slime pit? If the former, I would welcome suggestions about how best to use the existing osi_XXX() networking calls for this purpose. (They must be there for a reason; calling socket/connect/sendto may not be The Way, especially in a kernel module...)
Thanks for the bandwidth... -- +-----------------------------------------------------------------+ / [EMAIL PROTECTED] 919-962-5273 http://www.unc.edu/~utoddl / / A Freudian slip is when you say one thing but mean your mother. / +-----------------------------------------------------------------+
_______________________________________________ OpenAFS-devel mailing list [EMAIL PROTECTED] https://lists.openafs.org/mailman/listinfo/openafs-devel
