[prev in list] [next in list] [prev in thread] [next in thread] 

List:       netfilter-devel
Subject:    Re: [RFC] [PATCH] ctnetlink updates
From:       Harald Welte <laforge () netfilter ! org>
Date:       2005-04-29 8:02:42
Message-ID: 20050429080242.GJ9735 () sunbeam ! de ! gnumonks ! org
[Download RAW message or body]


On Fri, Apr 29, 2005 at 09:14:16AM +0200, Jozsef Kadlecsik wrote:
> I don't like id either. Conntrack can uniquely identified by
> 
> - src/dst tuples, globally, even in a cluster
> - the pointer of the conntrack entry, locally

Yes, but not over time, i.e. if your cycle of reading the table and
issuing a 'delete' is long enough, then you could remove a connection
that was using the same tuple but was established meanwhile (after the
old died).  However looking at current timeouts, that would be more than
one or two minutes delat between read and delete.

My point of view is that we don't need the ID.  If there is too much
delay, well then the user has a certain risk.   If we would call it
'deleting a flow' then we'd be safe, since a flow has no start and
beginning, and multiple successive connections can comprise one flow ;)

> Looking at the last changes, I think it'd be much more better to port
> ip_queue to nfnetlink than to reserve another netlink ID: the hooks in
> nfnetlink are already there. I know that'd create backward compatibility
> issues at the existing queue applications, though... :-(

We've discussed that with David Miller at netconf'04.  The result was
that we can get another NETLINK family,  as there is a number of
obsolete/outdated ones in the kernel at the moment.  Also, if we keep
ULOG and ip_queue for now, and later migrate them into nfnetlink, there
will be again more free numbers.

ip_queue needs to be renamed to pkt_queue or nf_queue and made layer3
independent.  Same goes for ULOG.  Also, ULOG should no longer have a
fixed header containing interface names, ... but rather have that
in TLV's that are added according to the rule specified by the admin.

I've alsos been thinking of experimenting with a mmap'ed ring buffer for
ulog... at least it would be worth investigating at some point.

> Best regards,
> Jozsef

-- 
- Harald Welte <laforge@netfilter.org>                 http://netfilter.org/
============================================================================
  "Fragmentation is like classful addressing -- an interesting early
   architectural error that shows how much experimentation was going
   on while IP was being designed."                    -- Paul Vixie

[Attachment #3 (application/pgp-signature)]

[prev in list] [next in list] [prev in thread] [next in thread]