[RELEASE] netlink for netfilter version 1.0.0

[Brad Chapman]

Mr. Morris,

--- James Morris <jmorris@intercode.com.au> wrote:
> On Sat, 17 Nov 2001, Brad Chapman wrote:
> 
> > > The biggest problem and cause of much ugliness is maintaining state
> > > between the queue handler and userspace, so that the kernel always knows
> > > what to do with incoming and already queued packets.
> >
> > 	If I may say, why bother keeping state? Just construct a broadcast
> > Netlink socket for ip_queue and allow everyone to do their own processing.
> > The Netlink clients themselves could do it, or ipqmpd could have life breathed
> > into it as a multiplexing Netlink processor that can be implemented in
> > userspace.
> >
> > 	Personally, sir, remove all the logic in the kernel and just broadcast
> > data. Let userspace do the processing, where IMVHO it belongs.
> >
> 
> Yes, a stateless queue in the kernel is an attractive idea.  At the
> moment, if there's no userspace process registered, packets are dropped
> without being queued.  With a stateless queue, the queue would just fill
> up and then start dropping packets if nothing was issuing verdicts.  I
> guess this could be a lesser evil than trying to maintain state between
> the queue and userspace.

	Agreed. And like you said in the other message, eventually ip_queue will
use the nfnetlink API, along with ip_conntrack and iptables. Do you think that
ipqmpd will become nfipqd or something, when nfnetlink either goes into 2.5 or
when you setup the stateless queue?

> 
> 
> - James
> -- 
> James Morris
> <jmorris@intercode.com.au>
> 
>

Brad 


=====
Brad Chapman

Permanent e-mail: kakadu_croc@yahoo.com
Current e-mail: kakadu@adelphia.net
Alternate e-mail: kakadu@netscape.net

__________________________________________________
Do You Yahoo!?
Buy the perfect holiday gifts at Yahoo! Shopping.
http://shopping.yahoo.com