From owner-freebsd-hackers  Sat Mar 22 21:56:42 1997
Return-Path: <owner-hackers>
Received: (from root@localhost)
          by freefall.freebsd.org (8.8.5/8.8.5) id VAA24778
          for hackers-outgoing; Sat, 22 Mar 1997 21:56:42 -0800 (PST)
Received: from awfulhak.demon.co.uk (awfulhak.demon.co.uk [158.152.17.1])
          by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id VAA24772
          for <hackers@freebsd.org>; Sat, 22 Mar 1997 21:56:32 -0800 (PST)
Received: from awfulhak.demon.co.uk (localhost.lan.awfulhak.org [127.0.0.1])
	by awfulhak.demon.co.uk (8.8.5/8.8.5) with ESMTP id FAA18935;
	Sun, 23 Mar 1997 05:54:12 GMT
Message-Id: <199703230554.FAA18935@awfulhak.demon.co.uk>
X-Mailer: exmh version 1.6.9 8/22/96
To: Archie Cobbs <archie@whistle.com>
cc: danny@panda.hilink.com.au, dfr@render.com, hackers@freebsd.org
Subject: Re: tun0/user ppp lockups? 
In-reply-to: Your message of "Sat, 22 Mar 1997 18:59:24 PST."
             <199703230259.SAA25573@bubba.whistle.com> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Sun, 23 Mar 1997 05:54:11 +0000
From: Brian Somers <brian@awfulhak.demon.co.uk>
Sender: owner-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

> 
> > Yeeeesss, I never did understand Whistle's reasons for leaving the divert(4)
> > stuff in "limbo" and *hinting* at it being useful.  I suspect there were
> > reasons that ought'nt to be discussed.
> 
> Well.. there's no conspiracy or anything. I wrote the divert code
> simply because it made it possible to completely separate the PPP
> stuff from the address translation stuff, which made development
> alltogether easier. It was only in "limbo" in the sense that for
> a while we seemed to be the only people using it :-) I wanted to
> release the address translation code as well but that was put on
> hold in order to protect our "competitive advantage" or some
> silliness like that... :-)

The only problem is with dynamic IPs.  What we really need is the
capability to trigger events that will tell natd (or whatever)
when an interface has been "changed".....

Then, natd could sit on an interface and do really smart things
rather than getting confused/restarted with every ifconfig.

Currently, natd could figure things out for incoming packets by
looking at the "from" address given by recvfrom(), but it has
no chance with outgoing packets ("from" is 0.0.0.0).  Maybe
"from" should be changed to be

    #define DIVERT_MAGIC ((u_char)123)
    #define DIR_IN 1
    #define DIR_OUT 2
    struct sockaddr_divert {
        u_char sa_len;
        u_char sa_family;
        u_short sin_port;
        struct in_addr sin_addr;
        u_char direction;
        u_char divert_magic;
        char sin_zero[6];
    }

Nice & compatible with sockaddr_in, and with the address of the
interface in question available in sin_addr, natd can "notice"
that it's been changed.

I would think the divert_magic bit is necessary so that the application
can tell if it's dealing with an old or new kernel
(sockaddr_in/sockaddr_divert).

Are there any major problems here that I'm missing ?
-- 
Brian <brian@awfulhak.demon.co.uk>, <brian@freebsd.org>
      <http://www.awfulhak.demon.co.uk/>
Don't _EVER_ lose your sense of humour....