Date: Tue, 3 Oct 2000 01:06:56 -0400 From: "Matthew Emmerton" <matt@gsicomp.on.ca> To: "Patrick Bihan-Faou" <patrick@mindstep.com>, <freebsd-net@FreeBSD.ORG> Subject: Re: natd and userland ppp Message-ID: <000a01c02cf7$c0cb0a10$1200a8c0@gsicomp.on.ca> References: <200010022329.e92NT9n37409@hak.lan.Awfulhak.org> <001101c02ccd$c1e96470$1200a8c0@gsicomp.on.ca> <038501c02ced$99936960$040aa8c0@local.mindstep.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> > > I think there's probably room for some sort of ascii interface to > > > libalias though, including (at least) the natd configuration file > > > parser. That way ppp could allow ``nat config /etc/natd.conf'' and > > > could have a generally more compatible (with natd) interface. > > > > And just in case anyone was wondering, I am currently working on a ``nat > > config <configfile>'' feature for ppp. I'm just taking lots of time > > determining the best way to do it, since there is a considerable amount of > > code from natd that needs to be added to ppp (in other words, the config > > file parser is around 25% of natd's total code.) > > Ouch, that hurts... > > 25% code porting calls for drastic measures... It would definitely be nice > to have the same code for these two tools. Maybe extending the library or > creating a new one, I don't know. But if the code is not the same, there > will be some divergence at some point and that will be painfull... There > must be a better way (although I don't have the answer). It's actually closer to 30% (gasp!). This is simply the code to parse configuration files (and command line arguments, which are essentially aliases for config file directives) and the data structures to support the parsing. The rest is just daemonizing code and wrappers around the functions in libalias. Due to the nature of this "common" code, I don't think it belongs in libalias, but since I don't forsee anything other than ppp requiring embedded nat capabilities (hmm, perhaps netgraph), I don't see the need for libnat on the horizon either. My current idea is to split out enough of the natd code into separate files so that the ppp code can just refer to a few source files from natd. This method comes with two main drawbacks -- the introduction of a source dependency across the usr.sbin and sbin source trees, as well as the need to make ppp and natd do option processing in similar fashions (which they don't really do right now.) Since I like the way natd's option processing is done now, I think that I'm going to be patching ppp to work with "the natd way" (subject to Brian's review, of course.) The only other option is to use netgraph. I'm thinking that a ng_nat module would eliminate some situations -- however the majority would be would be those requiring natd as a daemon (such as plain Ethernet or PPPoE) and not the nat-enabled user-ppp. -- Matthew Emmerton GSI Computer Services +1 (800) 217 5409 (Canada) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?000a01c02cf7$c0cb0a10$1200a8c0>