Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 14 Oct 2004 16:23:42 -0700
From:      Julian Elischer <julian@elischer.org>
To:        Andre Oppermann <oppermann@networx.ch>
Cc:        net@freebsd.org
Subject:   Re: small tun(4) improvement
Message-ID:  <416F0A7E.70207@elischer.org>
In-Reply-To: <416F0497.806DB456@networx.ch>
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>

next in thread | previous in thread | raw e-mail | index | archive | help


Andre Oppermann wrote:

>Julian Elischer wrote:
>  
>
>>Andre Oppermann wrote:
>>    
>>
>>>P.S. I'm working on making protocols within protocols domains loadable at
>>>least for IPv4.
>>>
>>>      
>>>
>>I did some work on this once.. things have got a lot more complicated
>>however with locking..
>>    
>>
>
>Actually there are not that many locking problems with the register and
>unregister functions themselfes.  It get a little bit more trickier with
>the stuff using these hooks though.
>
>  
>
>>>I'm using this to make DIVERT a loadable module.
>>>
>>>      
>>>
>>cool.. the trick is to work out how to make it (un)attach to ipfw..
>>    
>>
>
>DIVERT sockets in themselfes do not depend on ipfw.  You can send out
>packets just fine through a diver socket even when ipfw is missing.
>But you can't get any packets from the kernel unless ipfw puts them
>up to divert.  Nothing that prevents other uses or users of divert
>in the end (ng_divert perhaps...).
>

yes I know, that's how we wrote divert.. (to be independent)  netgraph 
came later..
I guess we would have done divert differently if we had done netgraph 
first..
probably would have given ipfw a "hook" command that sent
packets out a netfgaph hook to whatever was attached.. hmm that could 
still be really usefull...
a netgraph NAT module anyone?

>
>  
>



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?416F0A7E.70207>