Date: Fri, 15 Oct 2004 11:26:22 +0400 From: Gleb Smirnoff <glebius@freebsd.org> To: Julian Elischer <julian@elischer.org> Cc: net@freebsd.org Subject: Re: small tun(4) improvement Message-ID: <20041015072622.GC53159@cell.sick.ru> In-Reply-To: <416F0A7E.70207@elischer.org> References: <20041014174225.GB49508@cell.sick.ru> <416EBF0A.CB1C0366@networx.ch> <20041014202305.GA50360@cell.sick.ru> <416EE620.186AD27A@freebsd.org> <416F02CA.5020700@elischer.org> <416F0497.806DB456@networx.ch> <416F0A7E.70207@elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Oct 14, 2004 at 04:23:42PM -0700, Julian Elischer wrote: J> yes I know, that's how we wrote divert.. (to be independent) netgraph J> came later.. J> I guess we would have done divert differently if we had done netgraph J> first.. J> probably would have given ipfw a "hook" command that sent J> packets out a netfgaph hook to whatever was attached.. hmm that could J> still be really usefull... I have a snap code doing this. I have temporarily abandoned that node because, I can't imagine a way to put packets back to ipfw. ipfw is a function, which processes packet and returns. netgraph may queue packets. How can it inject them back into ipfw, so that 1) it is checked from the next rule, not first 2) it will be returned to ip_(input|output) ? J> a netgraph NAT module anyone? In far plans. First we need to solve the above problem with ifpw and netgraph interaction. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20041015072622.GC53159>