[ANNOUNCE] Summary of the netfilter developer workshop

Harald Welte laforge@gnumonks.org
Wed, 5 Dec 2001 22:59:54 +0100


On Tue, Dec 04, 2001 at 04:20:12AM -0800, Brad Chapman wrote:
> Mr. Harald,
> 
> > 5. Conntrack exepmtions
> > 
> >   In order to do exemptions to connection tracking, we would need to have 
> > a table attached to the PRE_ROUTING hook with a priority before conntrack
> > gets executed.  The table's name is 'notrack'.  The table would set up
> > the nfct field of the skb to point to some dummy conntrack entry.  The 
> > connection tracking core would then check against this dummy entry before
> > setting nfct.
> 
> 	Wonderful! Say "when" sometime this week and I'll have an early patch
> 	of this idea.

patches are always welcome.

> > 6. Five hooked mangle table
> > 
> >   We put the five hooked mangle table in patch-o-matic pending section of
> > patch-o-matic.  The mangle priority will be the same as currently.  After
> > checking if it breaks with old iptables binaries, we will submit it to the
> > mainstream kernel
> 
> 	Once again, thanks VERY much.

I'll do some more testing during this week and submit ASAP.

> > x removed unknown table (did we really fix the dropped-table problems?)
> 
> 	Yeah, BTW: what will happen to the dropped-table patch?

Please ask Rusty about it. 

> > 9. userspace tool iptables
> > 
> >   There are a couple of problems with the current approach of iptables:
> > 
> > - the plugins are bound to commandline parsing (getopt, ...) and thus not
> >   flexible enough for alternative interfaces (gui, firewall languages, ...)
> > - libiptc is extremely low-level and of no use if you don't know about the
> >   plugins and their datastructures
> > - the macro-based approach for iptables / ip6tables shared code is not the
> >   best idea.
> > 
> >   Results:
> > - libiptc is going to disappear, since in 2.5.x all rule changes (of the
> >   new linked list internal data structures) will be made using iptnetlink.
> > - the plugin handling and big parts of iptables will move into a new library
> >   called libiptables.  This library can be used to query the available matches
> >   and targets as well as their parameters, valid values, help, ...
> 
> 	How about the plugins? Will you just chain the plugins onto the current
> process accessing the libiptables functions

yes. an application can query libiptables about all available matches, targets
and their parameters.  libiptables will take care about everything else.

> > - multiple frontends (iptables style, ip/tc style, ...) will run on top of
> > this high-level library.  iptables style will be supported by the netfilter 
> >   project, other ones by 3rd party.
> 
> 	Cool! What about network-based administration? Something like SWAT for 
> Samba, where you can configure rules using a web browser?

That's not our problem.  We will provide libiptables and everybody is free
to use it (within GPL license terms, of course).  The netfilter core team
wants to focus on the low-level part, frontends can be done by other parties.

> >  are sent to userspace (netlink/syslog/...) for further analyzation
> 
> 	That sounds a little too static, especially with macros all over the 
> network stack. 

I don't see any problems with a couple of macro's spread through the code,
as long as the macros default to nothing in the normal kernel configuration.
Only if you compile a kernel with support for this packet tracing facility,
the macros will expand to something (like DEBUGP, ..)

> 	I don't think this is just a difficulty with ip_conntrack. I think in
> 	2.5, we (as in someone in the netfilter-devel community) are going to
> 	have to implement full fragment-scan stuff for conntrack/NAT, so that
> 	we won't be forced to bend the RFCs by defragging everything.
> 
> 	Was anything discussed regarding that?

No. Andras Kis-Szabo is now maintaining the IPv6 code, I don't have the time
to dive into it too much...

> > - milestones
> >        we don't want milestones.
> 
> 	Why not?

Because we don't have a project with difficult long-term goals, and don't 
want to exert too much pressure onto ourselves.

> > - new homepage
> >        page looks nice but the way it was built from templates is unsuitable
> >        for our needs since it requires proprietary windows software (eek!).
> >        New homepage will appear under www.netfilter.org / www.iptables.org,
> >        which are round-robin dns entries for the three (or even more) 
> >        sites.
> 
> 	I was wondering what had happened to the new webpage. Will it still be
> launching sometime soon? (I remember you saying a while ago that in about two
> weeks it would be up)

Please read: "unuitable because...".  I will fix that soon.

> > - CVS server
> >        will move to a seperate machine at gnumonks.org and get rsync'ed to
> >        samba.org for public access.  This way we can give more people cvs
> >        write access without needing more samba.org accounts.
> 
> 	"More people". What kind of policy will there be for gaining CVS write
> access so that people can work on the netfilter code?

As always, we want to be pragmatic and remain flexible.  We want to write
code, not policy.  If we see the need for somebody having CVS access, he 
will get it.

> Thanks,
> Brad

-- 
Live long and prosper
- Harald Welte / laforge@gnumonks.org               http://www.gnumonks.org/
============================================================================
GCS/E/IT d- s-: a-- C+++ UL++++$ P+++ L++++$ E--- W- N++ o? K- w--- O- M- 
V-- PS+ PE-- Y+ PGP++ t++ 5-- !X !R tv-- b+++ DI? !D G+ e* h+ r% y+(*)