From owner-freebsd-net@FreeBSD.ORG Tue Feb 8 01:33:34 2005 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 71D5E16A4CE; Tue, 8 Feb 2005 01:33:34 +0000 (GMT) Received: from mail.vicor-nb.com (bigwoop.vicor-nb.com [208.206.78.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 56D7E43D1F; Tue, 8 Feb 2005 01:33:34 +0000 (GMT) (envelope-from julian@elischer.org) Received: from elischer.org (julian.vicor-nb.com [208.206.78.97]) by mail.vicor-nb.com (Postfix) with ESMTP id 459BC7A423; Mon, 7 Feb 2005 17:33:34 -0800 (PST) Message-ID: <420816EE.5080906@elischer.org> Date: Mon, 07 Feb 2005 17:33:34 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.3.1) Gecko/20030516 X-Accept-Language: en, hu MIME-Version: 1.0 To: Gleb Smirnoff References: <200501250834.11393.darcy@wavefire.com> <20050207124637.GE91619@cell.sick.ru> <420766FF.714B372D@kuzbass.ru> <20050207131148.GA92617@cell.sick.ru> In-Reply-To: <20050207131148.GA92617@cell.sick.ru> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-net@freebsd.org cc: Darcy Buskermolen cc: Eugene Grosbein Subject: Re: ng_nat revisited X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2005 01:33:34 -0000 Gleb Smirnoff wrote: >On Mon, Feb 07, 2005 at 08:02:55PM +0700, Eugene Grosbein wrote: >E> > D> It's been a while since the subject of ng_nat appeared on-list, I'm wondering >E> > D> if there has been anymore work done on this? >E> > >E> > Now I'm trying to work on this. I don't guarantee any success in recent future. >E> > >E> > The first step is porting libalias to be a kernel module. I have already >E> > patches to make it compilable as kernel module, however with some features >E> > disabled - alias monitoring, sockets, and ipfw punching. The first two can >E> > be abandoned, but ipfw punching needs to be reimplemented in kernel. >E> >E> Why do you think alias monitoring may be abadoned? > >It does logging into file. It is difficult to implement same thing in kernel. >May be it will be substituted with bare log(9). > or have "monitor" hook.. > > >