Date: Sun, 23 Mar 1997 05:54:11 +0000 From: Brian Somers <brian@awfulhak.demon.co.uk> To: Archie Cobbs <archie@whistle.com> Cc: danny@panda.hilink.com.au, dfr@render.com, hackers@freebsd.org Subject: Re: tun0/user ppp lockups? Message-ID: <199703230554.FAA18935@awfulhak.demon.co.uk> In-Reply-To: Your message of "Sat, 22 Mar 1997 18:59:24 PST." <199703230259.SAA25573@bubba.whistle.com>
next in thread | previous in thread | raw e-mail | index | archive | help
>
> > 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....
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199703230554.FAA18935>