x_tables vs. nf-hipac

x_tables vs. nf-hipac

[Carl-Daniel Hailfinger]

Hi Harald,

you said that there is already some code for x_tables (is that 
pkttables, and if so, doesn't the new name collide with a spreadsheet 
layout program?). How does that relate to nf-hipac? Are they orthogonal 
to each other? Will both be merged into 2.6.$BIGNUM ? Which one is going 
to get in earlier?

Regards,
Carl-Daniel

Re: x_tables vs. nf-hipac

[Amin Azez]

Carl-Daniel Hailfinger wrote:
> Hi Harald,
> 
> you said that there is already some code for x_tables (is that
> pkttables, and if so, doesn't the new name collide with a spreadsheet
> layout program?). How does that relate to nf-hipac? Are they orthogonal
> to each other? Will both be merged into 2.6.$BIGNUM ? Which one is going
> to get in earlier?

I was also wondering this.
The rule structure and rapid update capability of nf-hipac looks very
attractive, it seems desirable to merge them in some way.

I while back someone elses posted a linked-list version of iptables that
also didn't require sending the whole rule structure to the kernel each
time, but nf-hipac seems to have additional optimisation in reducing the
number of repeated identical tests.

Sam

Re: x_tables vs. nf-hipac

[Harald Welte]

[-- Attachment #1: Type: text/plain, Size: 852 bytes --]

On Mon, Oct 10, 2005 at 01:05:53PM +0200, Carl-Daniel Hailfinger wrote:
> Hi Harald,
> 
> you said that there is already some code for x_tables (is that
> pkttables, and if so, doesn't the new name collide with a spreadsheet
> layout program?). 

No, x_tables is not pkttables.  However, x_tables matches/targets will
be incrementally changed in order to be used from
{arp,ip,ip6,pkt}_tables _and_ nf-hipac at the same time.

I don't care about spreadsheet programs.

-- 
- 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 #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: x_tables vs. nf-hipac

[Bart De Schuymer]

Op ma, 10-10-2005 te 18:34 +0200, schreef Harald Welte:
> On Mon, Oct 10, 2005 at 01:05:53PM +0200, Carl-Daniel Hailfinger wrote:
> > Hi Harald,
> > 
> > you said that there is already some code for x_tables (is that
> > pkttables, and if so, doesn't the new name collide with a spreadsheet
> > layout program?). 
> 
> No, x_tables is not pkttables.  However, x_tables matches/targets will
> be incrementally changed in order to be used from
> {arp,ip,ip6,pkt}_tables _and_ nf-hipac at the same time.

Nice to see this move forward. If you want to put the arptables
userspace tool into the netfilter tree, then be my guest.
I guess we'll have to consider talking about merging ebtables into this
scheme some day...

cheers,
Bart

Re: x_tables vs. nf-hipac

[Henrik Nordstrom]

On Mon, 10 Oct 2005, Bart De Schuymer wrote:

> Nice to see this move forward. If you want to put the arptables
> userspace tool into the netfilter tree

How different is the arptables userspace tool from the iptables userspace 
tool?

Regards
Henrik

Re: x_tables vs. nf-hipac

[Bart De Schuymer]

Op di, 11-10-2005 te 14:27 +0200, schreef Henrik Nordstrom:
> On Mon, 10 Oct 2005, Bart De Schuymer wrote:
> 
> > Nice to see this move forward. If you want to put the arptables
> > userspace tool into the netfilter tree
> 
> How different is the arptables userspace tool from the iptables userspace 
> tool?

It doesn't differ much, most code was copied without changes from
iptables. This was done a lot of months ago, so all changes to iptables
since then are not reflected in arptables. One thing though is that it
needs to distinguish between 2.4 and 2.6 kernels (the latter having the
arptables FORWARD chain).

cheers,
Bart

Re: x_tables vs. nf-hipac

[Harald Welte]

[-- Attachment #1: Type: text/plain, Size: 2803 bytes --]

On Mon, Oct 10, 2005 at 10:31:37PM +0000, Bart De Schuymer wrote:
> Op ma, 10-10-2005 te 18:34 +0200, schreef Harald Welte:
> > On Mon, Oct 10, 2005 at 01:05:53PM +0200, Carl-Daniel Hailfinger wrote:
> > > Hi Harald,
> > > 
> > > you said that there is already some code for x_tables (is that
> > > pkttables, and if so, doesn't the new name collide with a spreadsheet
> > > layout program?). 
> > 
> > No, x_tables is not pkttables.  However, x_tables matches/targets will
> > be incrementally changed in order to be used from
> > {arp,ip,ip6,pkt}_tables _and_ nf-hipac at the same time.
> 
> Nice to see this move forward. If you want to put the arptables
> userspace tool into the netfilter tree, then be my guest.

At the moment, I'm still busy in consolidation of kernelspace.  I'm not
sure how easy this will get for the userspace side.  Once I've done the
userspace counterpart (consolidation of libipt_FOO / libipXt_FOO), I'll
look at the arptables userspace code and see if we can integrate that
somehow.

One rally sad thing is that arp_tables was deprived of matches, so we
only have targets.  This means we cannot use any of the x_tables matches 
(such as limit, mark, ...).

> I guess we'll have to consider talking about merging ebtables into this
> scheme some day...

ebtables and x_tables has quite some 'impedance mismatch', mainly
because of lots of small subtle differences:

- FUNCTION_NAME_LENGTH is 32, not 30 (thus ebt_match/ebt_target have a
  different structure layout)
- different count of arguments for match(), target() and checkfn().

If you would be willing to harmonize here (I think this only affects
kernel space data structures that are not shared with userspace, so no
compatibility issues), then eb_tables could directly use x_tables
matches - if that is desired.


However, ebtables matches quite nicely with pkt_tables (some people have
suggested renaming it into nf_tables).  This is mainly because of the
"watchers".  A pkt_tables rule has 
- any number of matches
- any number of targets (that have a "void" function and don't return
  anything)
- one user-specified verdict.

so all watchers can be implemented as targets.  So it all boils down on
how much time I can find to complete pkt_tables. Maybe at some point
early 2006, after we've survived the nf_conntrack merge, and added
proper support for userspace conntrack helpers.

-- 
- 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 #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: x_tables vs. nf-hipac

[Bart De Schuymer]

Op di, 11-10-2005 te 16:33 +0200, schreef Harald Welte:
> At the moment, I'm still busy in consolidation of kernelspace.  I'm not
> sure how easy this will get for the userspace side.  Once I've done the
> userspace counterpart (consolidation of libipt_FOO / libipXt_FOO), I'll
> look at the arptables userspace code and see if we can integrate that
> somehow.
> 
> One rally sad thing is that arp_tables was deprived of matches, so we
> only have targets.  This means we cannot use any of the x_tables matches 
> (such as limit, mark, ...).

Yeah, I know. But I don't see why it can't be added, this shouldn't
break backwards compatibility. The struct arpt_entry has the members
target_offset and next_offset...

> If you would be willing to harmonize here (I think this only affects
> kernel space data structures that are not shared with userspace, so no
> compatibility issues), then eb_tables could directly use x_tables
> matches - if that is desired.

It's probably not worth it...

> However, ebtables matches quite nicely with pkt_tables (some people have
> suggested renaming it into nf_tables).  This is mainly because of the
> "watchers".  A pkt_tables rule has 
> - any number of matches
> - any number of targets (that have a "void" function and don't return
>   anything)
> - one user-specified verdict.
> 
> so all watchers can be implemented as targets.  So it all boils down on
> how much time I can find to complete pkt_tables. Maybe at some point
> early 2006, after we've survived the nf_conntrack merge, and added
> proper support for userspace conntrack helpers.

I'll wait for that then. Hopefully it will allow the RETURN verdict for
target modules. I'll concentrate on finalising the current ebtables
version in cvs for now.

cheers,
Bart

Re: x_tables vs. nf-hipac

[Harald Welte]

[-- Attachment #1: Type: text/plain, Size: 2574 bytes --]

On Tue, Oct 11, 2005 at 04:55:46PM +0000, Bart De Schuymer wrote:
> > One rally sad thing is that arp_tables was deprived of matches, so we
> > only have targets.  This means we cannot use any of the x_tables matches 
> > (such as limit, mark, ...).
> 
> Yeah, I know. But I don't see why it can't be added, this shouldn't
> break backwards compatibility. The struct arpt_entry has the members
> target_offset and next_offset...

ah, ok. That sounds good.  Maybe someone is willing to add match
support after x_tables is merged.

> > If you would be willing to harmonize here (I think this only affects
> > kernel space data structures that are not shared with userspace, so no
> > compatibility issues), then eb_tables could directly use x_tables
> > matches - if that is desired.
> 
> It's probably not worth it...

Yes, that's what I figured.
 
> > However, ebtables matches quite nicely with pkt_tables (some people have
> > suggested renaming it into nf_tables).  This is mainly because of the
> > "watchers".  A pkt_tables rule has 
> > - any number of matches
> > - any number of targets (that have a "void" function and don't return
> >   anything)
> > - one user-specified verdict.
> > 
> > so all watchers can be implemented as targets.  So it all boils down on
> > how much time I can find to complete pkt_tables. Maybe at some point
> > early 2006, after we've survived the nf_conntrack merge, and added
> > proper support for userspace conntrack helpers.
> 
> I'll wait for that then. Hopefully it will allow the RETURN verdict for
> target modules. I'll concentrate on finalising the current ebtables
> version in cvs for now.

As I said, target modules are "void" so they don't return anything.
It's userspace who tells the kernel what verdict to use.   userspace
Target plugins will probably try to choose a reasonable default (e.g.
DROP in the case of REJECT), but the sysadmin can override it.  

If a target really has to drop a packet (because of whatever problem, we
have the "hotdrop" mechanism.  But that should be the exception, not the
standard case.

Cheers,

btw: did you yet hav a chance to test my ebt_log/ebt_ulog changes?
-- 
- 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 #2: Type: application/pgp-signature, Size: 189 bytes --]