[OpenAFS-devel] Stop me before I NAT again...

[Derrick J Brashear]

On Mon, 29 Sep 2003, Todd M. Lewis wrote:

> 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,

Why? In general it's not a bad idea, but you don't want to make it the
default or suddenly every client is generating a lot of unneeded traffic.
no problem there.

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

It's been on my list (which never shrinks). Ideally you don't need a
configure option, just run-time configuration. I'm happy to argue merits
with people about it if there are people who think I'm nuts. I'd have to
look at code before I can make any code suggestions.