POM Xtables???

POM Xtables???

[Dave]

Hi there guys, I'm a bit frustrated with the whole Patch-O-Matic thing.

Something seems very weird with this whole thing, when I read the
message boards, I keep seeing references that state POM is outdated
and to use something called Xtables, but I have no idea what that is.

1)  When I go to Netfilter.com, I see the POM on the left side,
however I don't see anything about Xtables.
2)  When I read the Netfilter extentions how-to, it shows how to use
POM but mentions nothing about Xtables.
3)  When I go to the FTP and GIT sites, I see no references to
Xtables, only POM.

Yet, reading the message boards we should be using this Xtables, yet
there is no way to download it and there seems to be no documentation
on it.

Am I missing something here?

I guess what i'm looking for is.

1) Is there any way to download this Xtables?
2) Is there any documentation on how to use it?
3) Can we get a clarification on the main Netfilter site on these things?
4) If we are not to use POM, then why is it still listed on the site
in the main projects list.

Very confused here.

Thanks
-Dave

Re: POM Xtables???

[Jan Engelhardt]

On Friday 2008-06-27 19:54, Dave wrote:

>Hi there guys, I'm a bit frustrated with the whole Patch-O-Matic thing.
>
>Something seems very weird with this whole thing, when I read the
>message boards, I keep seeing references that state POM is outdated
>and to use something called Xtables, but I have no idea what that is.
>
>1)  When I go to Netfilter.com, I see the POM on the left side,
>however I don't see anything about Xtables.
>2)  When I read the Netfilter extentions how-to, it shows how to use
>POM but mentions nothing about Xtables.
>3)  When I go to the FTP and GIT sites, I see no references to
>Xtables, only POM.
>
>Yet, reading the message boards we should be using this Xtables, yet
>there is no way to download it and there seems to be no documentation
>on it.
>
>Am I missing something here?
>
>I guess what i'm looking for is.
>
>1) Is there any way to download this Xtables?

http://freshmeat.net/projects/xtables-addons/
http://jengelh.medozas.de/projects/xtables-addons/

>2) Is there any documentation on how to use it?

The package provides a few more modules; when installed, you use like
it you always use iptables. There is a bit of a README and an INSTALL
file in the tarball; after being built, the xtables-addons.8 manpage
is assembled and can be viewed with `man -l xtables-addons.8` (or the
normal `man xtables-addons` when installed) that explains the new
modules much like the iptables.8 manpage.

./configure && make && make install  itself does not need much 
documentation, but the modules have more documentation than 
they did in pom.

Improvements or suggestions are always welcome.


>3) Can we get a clarification on the main Netfilter site on these things?
>4) If we are not to use POM, then why is it still listed on the site
>in the main projects list.
>
>Very confused here.

I am not representing Netfilter.org, but as the author/maintainer, this 
is the state of affairs (also copied to website now):

* pom was designed to patch and recompile kernel (you like spending
  two hours on that? and then you notice a problem with the patch...)
* multiarch and endianess issues often ignored, making the modules
  not work on x86_64, much less on sparc64.
* some security issues - error handling was missing sometimes that
  could lead to an oops
* code was generally unreviewed
* pom modules have not received any real updates in months
* and from a purely maintenance pov: pom modules replicated the
  glue to work with multiple kernels in their files...

* xtables-addons conveniently builds modules to an existing kernel,
  saving packagers, users and developers a lot of time
(there is also an easy --but unimplemented-- way to patch a kernel if 
you want to have it built-in)
* code that has been imported from pom got the necessary fixups wrt.
  multiarch, endianess and everything that looked like a blatant
  violation of something
* speed improvements (e.g. in geoip)
* and it makes maintenance a lot easier

Re: POM Xtables???

[Dave]

Hi Jan,

Thanks a bunch for clearing that up, looks like I'll be busy reading
that Netfilter Module pdf you created.  I'm still confused a bit on
why none of this is mentioned on Netfilter.org. Is the official module
patch system still POM as far as the Netfilter guys are concerned?

From my inexperienced perspective and reading the message boards a
bit, it seems like POM is still the official patch system for
Netfilter as far as asking the Netfilter team goes, but the users are
recommending the Xtables-addons patch system instead.  Otherwise it
would make sense that Xtables would be included in FTP and GIT on the
Netfilter site. I can understand some of the extensions having their
own web sites, but for the core module patch system to be on another
site seems very strange to me.

Can any of the Netfilter team clarify.  Hopefully this clears up for
others reading this too.

Cheers
-Dave



On Fri, Jun 27, 2008 at 11:58 AM, Jan Engelhardt <jengelh@medozas.de> wrote:
>
> On Friday 2008-06-27 19:54, Dave wrote:
>
>>Hi there guys, I'm a bit frustrated with the whole Patch-O-Matic thing.
>>
>>Something seems very weird with this whole thing, when I read the
>>message boards, I keep seeing references that state POM is outdated
>>and to use something called Xtables, but I have no idea what that is.
>>
>>1)  When I go to Netfilter.com, I see the POM on the left side,
>>however I don't see anything about Xtables.
>>2)  When I read the Netfilter extentions how-to, it shows how to use
>>POM but mentions nothing about Xtables.
>>3)  When I go to the FTP and GIT sites, I see no references to
>>Xtables, only POM.
>>
>>Yet, reading the message boards we should be using this Xtables, yet
>>there is no way to download it and there seems to be no documentation
>>on it.
>>
>>Am I missing something here?
>>
>>I guess what i'm looking for is.
>>
>>1) Is there any way to download this Xtables?
>
> http://freshmeat.net/projects/xtables-addons/
> http://jengelh.medozas.de/projects/xtables-addons/
>
>>2) Is there any documentation on how to use it?
>
> The package provides a few more modules; when installed, you use like
> it you always use iptables. There is a bit of a README and an INSTALL
> file in the tarball; after being built, the xtables-addons.8 manpage
> is assembled and can be viewed with `man -l xtables-addons.8` (or the
> normal `man xtables-addons` when installed) that explains the new
> modules much like the iptables.8 manpage.
>
> ./configure && make && make install  itself does not need much
> documentation, but the modules have more documentation than
> they did in pom.
>
> Improvements or suggestions are always welcome.
>
>
>>3) Can we get a clarification on the main Netfilter site on these things?
>>4) If we are not to use POM, then why is it still listed on the site
>>in the main projects list.
>>
>>Very confused here.
>
> I am not representing Netfilter.org, but as the author/maintainer, this
> is the state of affairs (also copied to website now):
>
> * pom was designed to patch and recompile kernel (you like spending
>  two hours on that? and then you notice a problem with the patch...)
> * multiarch and endianess issues often ignored, making the modules
>  not work on x86_64, much less on sparc64.
> * some security issues - error handling was missing sometimes that
>  could lead to an oops
> * code was generally unreviewed
> * pom modules have not received any real updates in months
> * and from a purely maintenance pov: pom modules replicated the
>  glue to work with multiple kernels in their files...
>
> * xtables-addons conveniently builds modules to an existing kernel,
>  saving packagers, users and developers a lot of time
> (there is also an easy --but unimplemented-- way to patch a kernel if
> you want to have it built-in)
> * code that has been imported from pom got the necessary fixups wrt.
>  multiarch, endianess and everything that looked like a blatant
>  violation of something
> * speed improvements (e.g. in geoip)
> * and it makes maintenance a lot easier
>

Re: POM Xtables???

[Jan Engelhardt]

On Friday 2008-06-27 22:08, Dave wrote:

>Hi Jan,
>
>Thanks a bunch for clearing that up, looks like I'll be busy reading
>that Netfilter Module pdf you created.

It is mostly for developers or those who want to become one,
but of course you can read it nevertheless.


>I'm still confused a bit on why none of this is mentioned on 
>Netfilter.org. Is the official module patch system still POM as far as 
>the Netfilter guys are concerned?

The following I found by chance in a mail archive...

>From: kaber at trash.net (Patrick McHardy)
>Date: Wed Apr  5 16:03:47 2006
>Subject: Update: Patch-o-matic cleanup
>
>Removing old patches is part of a greater plan to reduce the content
>of pom to only those things the netfilter team has an interest in
>maintaining, and most of these things will be merged in not too long
>time. _All_ other patches will be removed [...] [P]eople interested
>in keeping patches around can maintain them themselves and publish
>them somewhere for others to use. This should benefit both us and
>the authors since they usually maintain their own versions of the
>patches anyway and periodically send us updates to include in pom,
>which unnecessarily cost time for everyone involved.

The action depicted was carried out in May 2006, 
http://tinyurl.com/5c7lno .


I might add that I'd be happy to receive updates, additions or
new modules to Xtables-addons.
Because if you don't, I take it this project is already
flawless and perfect ;-)

Re: POM Xtables???

[Grant Taylor]

On 6/27/2008 1:58 PM, Jan Engelhardt wrote:
> (there is also an easy --but unimplemented-- way to patch a kernel if 
> you want to have it built-in)

Can I get some more information or pointers on what to read about 
including things in the kernel?



Grant. . . .

Re: POM Xtables???

[Dave]

Over the weekend I managed to get the Xtables-addons working with
Kernel 2.6.25.  Throughout this process many questions have come up
that were unanswered by the documentation or Netfilter site.  I'll
point them out.

1) Confusion on just what Xtables is.  Is Xtables really just
Iptables?  It seems to be, but there is nothing saying so officially.
2) Is Xtables the same things as Xtables-addons, Jan in your
directory, the files go from Xtables..... to Xtables-addons.... , does
this mean they are the same thing or different?
3) Still don't know where Xtables-addons fits in with Netfilter?  Why
is Xtables not on the Netfilter site or even mentioned there at all?
What does the core Netfilter team think of Xtables-addons?
4) How does one patch for ACCOUNT and IPSET?  I couldn't find any
modules for Xtables-addons to patch for these extensions, although I
did find mention of a xt_account extension, but couldn't find any
download or anyway to add it to addons.  I had to patch ACCOUNT and
IPSET with Patch-O-Matic.  It seems we really have to use both these
patchers to get everything.
5) Who wrote the extensions for Xtables-addons?  If there is a problem
with any of them where do we report, looking through the source I
couldn't find any writers or maintainers.
6) Currently the extensions and patching systems seems to be a
hodge-podge of items, all with different web sites, maintainers and
writers, from a newbie perspective it's confusing, would be nice if it
was wrapped up into something more straitforward. Hopefully this is
what Xtables-addons is doing, BUT would be really nice if this all
started officially at Netfilter.org.


Hopefully this helps.
Thanks for the great network utilities!
-Dave

On Sat, Jun 28, 2008 at 7:20 PM, Grant Taylor <gtaylor@riverviewtech.net> wrote:
> On 6/27/2008 1:58 PM, Jan Engelhardt wrote:
>>
>> (there is also an easy --but unimplemented-- way to patch a kernel if you
>> want to have it built-in)
>
> Can I get some more information or pointers on what to read about including
> things in the kernel?
>
>
>
> Grant. . . .
> --
> To unsubscribe from this list: send the line "unsubscribe netfilter" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

Re: POM Xtables???

[Patrick McHardy]

Dave wrote:
> Over the weekend I managed to get the Xtables-addons working with
> Kernel 2.6.25.  Throughout this process many questions have come up
> that were unanswered by the documentation or Netfilter site.  I'll
> point them out.
> 
> 1) Confusion on just what Xtables is.  Is Xtables really just
> Iptables?  It seems to be, but there is nothing saying so officially.

x_tables is the common core behind ip_tables, ip6_tables and
arp_tables.

> 3) Still don't know where Xtables-addons fits in with Netfilter?  Why
> is Xtables not on the Netfilter site or even mentioned there at all?
> What does the core Netfilter team think of Xtables-addons?

I have no opinion about this except that already mentioned by
Jan: useful patches in proper state should be upstream, all
others I don't care about.

> 4) How does one patch for ACCOUNT and IPSET?  I couldn't find any
> modules for Xtables-addons to patch for these extensions, although I
> did find mention of a xt_account extension, but couldn't find any
> download or anyway to add it to addons.  I had to patch ACCOUNT and
> IPSET with Patch-O-Matic.  It seems we really have to use both these
> patchers to get everything.

ipset is an exception as its the only patch maintained by
someone from the Core Team that has not been merged upstream
yet. As such it shouldn't be included in Jan's package since
Jozsef is doing official releases in pom.

> 6) Currently the extensions and patching systems seems to be a
> hodge-podge of items, all with different web sites, maintainers and
> writers, from a newbie perspective it's confusing, would be nice if it
> was wrapped up into something more straitforward. Hopefully this is
> what Xtables-addons is doing, BUT would be really nice if this all
> started officially at Netfilter.org.

Short answer - don't do it, the module provided by the kernel
should be enough for 99.99% of all cases. If it isn't, convince
us to merge the patch, which usually isn't very hard.

History has repeatedly shown that out of tree patches are buggy
and cause more problems than they solve, which is why there
is no interest from the netfilter team in maintaining external
patches (with the one exception of ipset, which is not considered
ready for upstream yet by Jozsef, its author).

Re: POM Xtables???

[Jan Engelhardt]

On Monday 2008-06-30 18:20, Patrick McHardy wrote:
>
>> 3) Still don't know where Xtables-addons fits in with Netfilter?  Why
>> is Xtables not on the Netfilter site or even mentioned there at all?
>> What does the core Netfilter team think of Xtables-addons?
>
> I have no opinion about this except that already mentioned by
> Jan: useful patches in proper state should be upstream, all
> others I don't care about.

Well at least I want to give it some care. POM, and Xtables-addons
exist because modules were rejected upstream.

- xt_CHAOS, xt_DELUDE, xt_portscan:
  http://lkml.org/lkml/2007/3/8/218 ("what do we gain?")

- xt_IPMARK: http://marc.info/?l=netfilter-devel&m=121148746823147&w=2
  ("Thats another special-casing module, exactly
  the think I *don't* like. How many more of these (with slightly
  differing semantic and features) should we add?")

- sample modules (xt_ECHO)
  These obviously don't belong into the kernel.

- the rest: dunno?


>> 4) How does one patch for ACCOUNT and IPSET?  I couldn't find any
>> modules for Xtables-addons to patch for these extensions, although I
>> did find mention of a xt_account extension, but couldn't find any
>> download or anyway to add it to addons.  I had to patch ACCOUNT and
>> IPSET with Patch-O-Matic.  It seems we really have to use both these
>> patchers to get everything.
>
> ipset is an exception as its the only patch maintained by
> someone from the Core Team that has not been merged upstream
> yet. As such it shouldn't be included in Jan's package since
> Jozsef is doing official releases in pom.

ACCOUNT and a few others (IMQ, layer7) do not use pom.
ipset does not actively live in pom, but strangely uses its patch
system... well it's perhaps the only one that still does ;-)

ipset is kinda floating. Joszef wanted to revamp it into a
nf_ipset, but nothing has surfaced so far. (Well, neither has my
ultimate code unification, heh.) It's a special case.

So for the above-mentioned three (ACCOUNT et al) you would just
use their documented method aka `patch -p1 -i /path/to/account.diff`
and hope that it works. Of course it would be much nicer if they
could make use of the kernel version glue in Xtables-addons.

>> 6) Currently the extensions and patching systems seems to be a
>> hodge-podge of items, all with different web sites, maintainers and
>> writers, from a newbie perspective it's confusing, would be nice if it
>> was wrapped up into something more straitforward. Hopefully this is
>> what Xtables-addons is doing, BUT would be really nice if this all
>> started officially at Netfilter.org.
>
> Short answer - don't do it, the module provided by the kernel
> should be enough for 99.99% of all cases. If it isn't, convince
> us to merge the patch, which usually isn't very hard.
>
> History has repeatedly shown that out of tree patches are buggy
> and cause more problems than they solve, which is why there
> is no interest from the netfilter team in maintaining external
> patches.

Hence I have taken up some and fixed them to be straight.
Patrick, what's your judgment on the existing
xt_{LOGMARK,TARPIT,TEE,condition,geoip,ipp2p} modules in xtables-addons?

Re: POM Xtables???

[Patrick McHardy]

Jan Engelhardt wrote:
> On Monday 2008-06-30 18:20, Patrick McHardy wrote:
>   
>>> 3) Still don't know where Xtables-addons fits in with Netfilter?  Why
>>> is Xtables not on the Netfilter site or even mentioned there at all?
>>> What does the core Netfilter team think of Xtables-addons?
>>>       
>> I have no opinion about this except that already mentioned by
>> Jan: useful patches in proper state should be upstream, all
>> others I don't care about.
>>     
>
> Well at least I want to give it some care. POM, and Xtables-addons
> exist because modules were rejected upstream.
> ...
> - the rest: dunno?
>   

Which rest? Is the list at the end of your mail complete?

>>> 6) Currently the extensions and patching systems seems to be a
>>> hodge-podge of items, all with different web sites, maintainers and
>>> writers, from a newbie perspective it's confusing, would be nice if it
>>> was wrapped up into something more straitforward. Hopefully this is
>>> what Xtables-addons is doing, BUT would be really nice if this all
>>> started officially at Netfilter.org.
>>>       
>> Short answer - don't do it, the module provided by the kernel
>> should be enough for 99.99% of all cases. If it isn't, convince
>> us to merge the patch, which usually isn't very hard.
>>
>> History has repeatedly shown that out of tree patches are buggy
>> and cause more problems than they solve, which is why there
>> is no interest from the netfilter team in maintaining external
>> patches.
>>     
>
> Hence I have taken up some and fixed them to be straight.
> Patrick, what's your judgment on the existing
> xt_{LOGMARK,TARPIT,TEE,condition,geoip,ipp2p} modules in xtables-addons?
>   

- LOGMARK - haven't seen it or can't remember
- TARPIT - fine if remaining issues are fixed
- TEE - same as TARPIT
- condition - undecided
- geoip - seems like a toy. Whats the use case?
- ipp2p - last version I've seen was a *horrible* mess, unless I'm
  confusing it with the other l7 classifier module out there.

Re: POM Xtables???

[Jozsef Kadlecsik]

On Mon, 30 Jun 2008, Patrick McHardy wrote:

> - LOGMARK - haven't seen it or can't remember

It adds the possibility to log the mark values of the packet/corresponding 
conntrack entry via syslog. 

The feature should simply be added to the LOG target, there's no real 
point to keep a separated target, as far as I see.

Best regards,
Jozsef
-
E-mail  : kadlec@blackhole.kfki.hu, kadlec@mail.kfki.hu
PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : KFKI Research Institute for Particle and Nuclear Physics
          H-1525 Budapest 114, POB. 49, Hungary

Re: POM Xtables???

[Patrick McHardy]

Jozsef Kadlecsik wrote:
> On Mon, 30 Jun 2008, Patrick McHardy wrote:
> 
>> - LOGMARK - haven't seen it or can't remember
> 
> It adds the possibility to log the mark values of the packet/corresponding 
> conntrack entry via syslog. 
> 
> The feature should simply be added to the LOG target, there's no real 
> point to keep a separated target, as far as I see.

I agree. In fact I already added this to ipt_LOG/ip6t_LOG in
2.6.26-rc :)

Re: POM Xtables???

[Jan Engelhardt]

On Tuesday 2008-07-01 11:46, Patrick McHardy wrote:

> Jozsef Kadlecsik wrote:
>> On Mon, 30 Jun 2008, Patrick McHardy wrote:
>> 
>> > - LOGMARK - haven't seen it or can't remember
>> 
>> It adds the possibility to log the mark values of the packet/corresponding
>> conntrack entry via syslog. 
>> The feature should simply be added to the LOG target, there's no real point
>> to keep a separated target, as far as I see.
>
> I agree. In fact I already added this to ipt_LOG/ip6t_LOG in
> 2.6.26-rc :)

You only added the nfmark, and it is printed unconditionally at that,
the latter of which I do not see as thrilling. Seems like it is time
for a new revision? Also I think the two modules should be unified
first.

LOGMARK was also instantiated on January 30 already, so that's
prior art here :)

Re: POM Xtables???

[Patrick McHardy]

Jan Engelhardt wrote:
> On Tuesday 2008-07-01 11:46, Patrick McHardy wrote:
> 
>> Jozsef Kadlecsik wrote:
>>> On Mon, 30 Jun 2008, Patrick McHardy wrote:
>>>
>>>> - LOGMARK - haven't seen it or can't remember
>>> It adds the possibility to log the mark values of the packet/corresponding
>>> conntrack entry via syslog. 
>>> The feature should simply be added to the LOG target, there's no real point
>>> to keep a separated target, as far as I see.
>> I agree. In fact I already added this to ipt_LOG/ip6t_LOG in
>> 2.6.26-rc :)
> 
> You only added the nfmark, and it is printed unconditionally at that,
> the latter of which I do not see as thrilling. Seems like it is time
> for a new revision? Also I think the two modules should be unified
> first.

It doesn't need a new revision, it doesn't affect the userspace
API in any way. As for the argument of parsers that might not
handle this: any parser needs to expect new things to be added
at the end of the line, otherwise its giving us no possibility
of ever extending the output, which is not reasonable.

Re: POM Xtables???

[Jan Engelhardt]

On Tuesday 2008-07-01 13:43, Patrick McHardy wrote:
>> You only added the nfmark, and it is printed unconditionally at that,
>> the latter of which I do not see as thrilling. Seems like it is time
>> for a new revision? Also I think the two modules should be unified
>> first.
>
> It doesn't need a new revision, it doesn't affect the userspace
> API in any way. As for the argument of parsers that might not
> handle this: any parser needs to expect new things to be added
> at the end of the line, otherwise its giving us no possibility
> of ever extending the output, which is not reasonable.
>
That is why LOGMARK has been LOGMARK so far, where the (undocumented)
requirement is that parsers have to split at whitespace and may not
assume any particular order of fields. This allows to selectively log
things by means of flags passed in from userspace and thus sparing
syslog from being spammed with unwanted fields.
So the only way is to introduce a LOG2 target?

Re: POM Xtables???

[Patrick McHardy]

Added netfilter-devel to CC.

Jan Engelhardt wrote:
> On Tuesday 2008-07-01 13:43, Patrick McHardy wrote:
>>> You only added the nfmark, and it is printed unconditionally at that,
>>> the latter of which I do not see as thrilling. Seems like it is time
>>> for a new revision? Also I think the two modules should be unified
>>> first.
>> It doesn't need a new revision, it doesn't affect the userspace
>> API in any way. As for the argument of parsers that might not
>> handle this: any parser needs to expect new things to be added
>> at the end of the line, otherwise its giving us no possibility
>> of ever extending the output, which is not reasonable.
>>
> That is why LOGMARK has been LOGMARK so far, where the (undocumented)
> requirement is that parsers have to split at whitespace and may not
> assume any particular order of fields. This allows to selectively log
> things by means of flags passed in from userspace and thus sparing
> syslog from being spammed with unwanted fields.

Spammed with unwanted fields in a huge exaggeration. And nobody
sane is using LOG for anything but debugging anyway due to the
unreliable nature of the ringbuffer and the huge slowdown this
might cause when using serial console.

> So the only way is to introduce a LOG2 target?

Only way for what? As I stated, you're free to add new fields
at the end.

Re: POM Xtables???

[Grant Taylor]

On 07/01/08 06:43, Patrick McHardy wrote:
> As for the argument of parsers that might not handle this: any parser 
> needs to expect new things to be added at the end of the line...

*LOL*

Now you are expecting people to do what they should verses what is easy.

Unfortunately, what is considered best practice (at the time) is not 
followed often enough.

(Joke)  Why don't we just log in XML and parse it out later.  :P~



Grant. . . .

Re: POM Xtables???

[Patrick McHardy]

Please don't trim CC lists.

Grant Taylor wrote:
> On 07/01/08 06:43, Patrick McHardy wrote:
>> As for the argument of parsers that might not handle this: any parser 
>> needs to expect new things to be added at the end of the line...
>
> *LOL*
>
> Now you are expecting people to do what they should verses what is easy.
>
> Unfortunately, what is considered best practice (at the time) is not 
> followed often enough.


We had multiple format extensions over time, you would hope
that people learn from their mistakes. Using scanf or a
lexer+scanner its probably impossible to even make this mistake,
assuming some perl parser someone would have to specifically
match on the (completely useless for parsing purposes) end of
line.

In any case, its unreasonable to expect us to never *extend*
(not change) the output to accomodate buggy parsers. This is
by the way the same way that is often used to extend binary
structures, even though someone stupid might use exact size
checks.

Re: POM Xtables???

[Grant Taylor]

On 07/01/08 09:10, Patrick McHardy wrote:
> In any case, its unreasonable to expect us to never *extend* (not 
> change) the output to accomodate buggy parsers. This is by the way 
> the same way that is often used to extend binary structures, even 
> though someone stupid might use exact size checks.

*nod*

Agreed.

However as I sit here and think about it, it may be worth adding a new 
field *as early as possible* (read closes to the start of line) in the 
field list that indicates a version, which can be used to determine the 
fields and their position there in.  This would make it very easy for 
people to write strict parsers down the road.  A simple three character 
hex field (4 bytes including the leading space) would allow for 4k of 
strict layouts.  (Even more 0-9 and a-z or additionally A-Z.) Just a 
thought.



Grant. . . .

Re: POM Xtables???

[Patrick McHardy]

Again, please don't trim CC lists.

Grant Taylor wrote:
> On 07/01/08 09:10, Patrick McHardy wrote:
>> In any case, its unreasonable to expect us to never *extend* (not 
>> change) the output to accomodate buggy parsers. This is by the way 
>> the same way that is often used to extend binary structures, even 
>> though someone stupid might use exact size checks.
>
> *nod*
>
> Agreed.
>
> However as I sit here and think about it, it may be worth adding a new 
> field *as early as possible* (read closes to the start of line) in the 
> field list that indicates a version, which can be used to determine 
> the fields and their position there in.  This would make it very easy 
> for people to write strict parsers down the road.  A simple three 
> character hex field (4 bytes including the leading space) would allow 
> for 4k of strict layouts.  (Even more 0-9 and a-z or additionally 
> A-Z.) Just a thought.

I don't it would be very useful at this time since we already made
those changes over the time of multiple years, so basically the
damage (if any) is already done.

And we have ULOG and nfnetlink_log that should be used for anything
serious for the reasons I stated earlier (more reliable, doesn't block
when using serial consoles, ...).

Re: POM Xtables???

[Jan Engelhardt]

On Tuesday 2008-07-01 16:05, Grant Taylor wrote:

> On 07/01/08 06:43, Patrick McHardy wrote:
>> As for the argument of parsers that might not handle this: any parser needs
>> to expect new things to be added at the end of the line...
>
> *LOL*
>
> Now you are expecting people to do what they should verses what is easy.
>
> Unfortunately, what is considered best practice (at the time) is not followed
> often enough.
>
> (Joke)  Why don't we just log in XML and parse it out later.  :P~

Why don't we just rip out LOG and instead force users to use NFLOG,
then all these things are hidden and they control how nflogd
outputs it. Hm?

Re: POM Xtables???

[Jan Engelhardt]

Still had this in the Draft folder..

On Monday 2008-06-30 22:52, Patrick McHardy wrote:
>
> Which rest? Is the list at the end of your mail complete?

Just contains those you have not yet rejected ;-)

>> Hence I have taken up some and fixed them to be straight.
>> Patrick, what's your judgment on the existing
>> xt_{LOGMARK,TARPIT,TEE,condition,geoip,ipp2p} modules in xtables-addons?
>>   
>
> - LOGMARK - haven't seen it or can't remember

Prints everything that LOG is missing, like nfmark, ctmark, secmark,
connection state, status. Quite useful when toying around with
fwmark-based policy routing.

> - TARPIT - fine if remaining issues are fixed
> - TEE - same as TARPIT
> - condition - undecided
> - geoip - seems like a toy. Whats the use case?

Matching on countries and (possibly) blocking them. People have
philosophized in the past whether (or not) it could use ipset;
right now it uses a binary search over ipranges, which is at least
a known good denominator.

> - ipp2p - last version I've seen was a *horrible* mess, unless I'm
> confusing it with the other l7 classifier module out there.

It was ugly from a codingstyle pov, which was fixed. It inspects
packets 

xt_ipp2p I gave it some care and a cleanup. it also "works", that is, it 
matches on bittorrent (something I could test), not all 
(data) connections though, but I guess the control connections are in.

Re: POM Xtables???

[Patrick McHardy]

Jan Engelhardt wrote:
> Still had this in the Draft folder..
> 
> On Monday 2008-06-30 22:52, Patrick McHardy wrote:
>> Which rest? Is the list at the end of your mail complete?
> 
> Just contains those you have not yet rejected ;-)

Rejections are not necessarily permanent .. but they may require
some convincing. Sometimes the mind just changes over time and
sometimes a convincing argument that it won't make things worse
is needed.

Which is just a general comment, I can only partially remember
which ones I've rejected :)

>>> Hence I have taken up some and fixed them to be straight.
>>> Patrick, what's your judgment on the existing
>>> xt_{LOGMARK,TARPIT,TEE,condition,geoip,ipp2p} modules in xtables-addons?
>>>   
>> - LOGMARK - haven't seen it or can't remember
> 
> Prints everything that LOG is missing, like nfmark, ctmark, secmark,
> connection state, status. Quite useful when toying around with
> fwmark-based policy routing.

I believe we've discussed this already, just add it to the end
of the MARK output. That would also be most useful since thats
what people already use. ctmark would also be useful for nfnetlink.

>> - TARPIT - fine if remaining issues are fixed

I actually would be quite happy to merge this or help fix the
remaining issues since I know a lot of people use this for
spam trapping.

>> - TEE - same as TARPIT

This one as well (well, the packet duplication feature,
I'm not sure whether it also included some routing hacks).

>> - condition - undecided
>> - geoip - seems like a toy. Whats the use case?
> 
> Matching on countries and (possibly) blocking them. People have
> philosophized in the past whether (or not) it could use ipset;
> right now it uses a binary search over ipranges, which is at least
> a known good denominator.

Evgeniy submitted an updated version, I think we already discussed
everything there (IIRC you followed that discussion). A u32 based
replacement would be the preferred choice, and also a nice precedent
that not every userspace match necessarily needs a corresponding
kernel module.

>> - ipp2p - last version I've seen was a *horrible* mess, unless I'm
>> confusing it with the other l7 classifier module out there.
> 
> It was ugly from a codingstyle pov, which was fixed. It inspects
> packets 
> 
> xt_ipp2p I gave it some care and a cleanup. it also "works", that is, it 
> matches on bittorrent (something I could test), not all 
> (data) connections though, but I guess the control connections are in.

Just send it to netfilter-devel. If its the thing with lots
of hard-coded binary matches full of magic values I'm not
interested :) I'd be more interested in a discussion what
would be necessary to represent all those matches through
the FSM textsearch match or something similar.

Re: POM Xtables???

[James King]

On Wed, Jul 23, 2008 at 4:21 PM, Patrick McHardy wrote:

>>> - ipp2p - last version I've seen was a *horrible* mess, unless I'm
>>> confusing it with the other l7 classifier module out there.
>>
>> It was ugly from a codingstyle pov, which was fixed. It inspects
>> packets
>> xt_ipp2p I gave it some care and a cleanup. it also "works", that is, it
>> matches on bittorrent (something I could test), not all (data) connections
>> though, but I guess the control connections are in.
>
> Just send it to netfilter-devel. If its the thing with lots
> of hard-coded binary matches full of magic values I'm not
> interested :) I'd be more interested in a discussion what
> would be necessary to represent all those matches through
> the FSM textsearch match or something similar.

ipp2p is the one with hard coded magic values.

What are your feelings on the kernel version of l7filter (regex
patterns loaded from the filesystem)?  Currently it requires a patch
to add a structure to nf_conn, but I've been meaning to rewrite it to
use ct_extend so that it could at least be included into xtables-addon
and used with a stock kernel, although if there's interest in having
it merged into mainline I'd be willing to focus on that.  One thing
I'm not sure of is whether the license used by the Henry Spencer regex
library it depends on is acceptable by kernel standards (or whether
it's permissive enough to relicense under GPL, as IANAL).

Re: POM Xtables???

[Pablo Neira Ayuso]

James King wrote:
> On Wed, Jul 23, 2008 at 4:21 PM, Patrick McHardy wrote:
> 
>>>> - ipp2p - last version I've seen was a *horrible* mess, unless I'm
>>>> confusing it with the other l7 classifier module out there.
>>> It was ugly from a codingstyle pov, which was fixed. It inspects
>>> packets
>>> xt_ipp2p I gave it some care and a cleanup. it also "works", that is, it
>>> matches on bittorrent (something I could test), not all (data) connections
>>> though, but I guess the control connections are in.
>> Just send it to netfilter-devel. If its the thing with lots
>> of hard-coded binary matches full of magic values I'm not
>> interested :) I'd be more interested in a discussion what
>> would be necessary to represent all those matches through
>> the FSM textsearch match or something similar.
> 
> ipp2p is the one with hard coded magic values.
> 
> What are your feelings on the kernel version of l7filter (regex
> patterns loaded from the filesystem)?  Currently it requires a patch
> to add a structure to nf_conn, but I've been meaning to rewrite it to
> use ct_extend so that it could at least be included into xtables-addon
> and used with a stock kernel, although if there's interest in having
> it merged into mainline I'd be willing to focus on that.  One thing
> I'm not sure of is whether the license used by the Henry Spencer regex
> library it depends on is acceptable by kernel standards (or whether
> it's permissive enough to relicense under GPL, as IANAL).

If we want to do this in-kernel I think that it's better if it must use
the textsearch infrastructure. Probably it would require some patches to
extend the existing infrastructure.

The other choise is userspace by means NFQUEUE. If we use some
heuristics, we may try to classify the traffic by means of the initial
data packets and then mark the connection. Thus, the number of packets
that go to userspace would be small and the classification logic is
implemented in userspace using whatever regex
engine/aho-corasick/bit-wise/boyer-moore/bayes whatsoever...

-- 
"Los honestos son inadaptados sociales" -- Les Luthiers

Re: POM Xtables???

[Patrick McHardy]

Pablo Neira Ayuso wrote:
> James King wrote:
>> On Wed, Jul 23, 2008 at 4:21 PM, Patrick McHardy wrote:
>>
>>> Just send it to netfilter-devel. If its the thing with lots
>>> of hard-coded binary matches full of magic values I'm not
>>> interested :) I'd be more interested in a discussion what
>>> would be necessary to represent all those matches through
>>> the FSM textsearch match or something similar.
 >>
>> ipp2p is the one with hard coded magic values.
>>
>> What are your feelings on the kernel version of l7filter (regex
>> patterns loaded from the filesystem)?  Currently it requires a patch
>> to add a structure to nf_conn, but I've been meaning to rewrite it to
>> use ct_extend so that it could at least be included into xtables-addon
>> and used with a stock kernel, although if there's interest in having
>> it merged into mainline I'd be willing to focus on that.

That is definitely a much better way than to hardcode the
matches. I think there is some interest in having this in
the kernel, yes.

>> One thing
>> I'm not sure of is whether the license used by the Henry Spencer regex
>> library it depends on is acceptable by kernel standards (or whether
>> it's permissive enough to relicense under GPL, as IANAL).

I know of the regexp.old.zip library, which IIRC used a GPL
compatible license (and a non-POSIX conform interface).

> If we want to do this in-kernel I think that it's better if it must use
> the textsearch infrastructure. Probably it would require some patches to
> extend the existing infrastructure.

I'd also prefer that over adding a regex library to the kernel.
I think one of the bigger problems is that there are dependencies
in the match that can't be easily expressed, like "byte 4 has
skb->len - 10". At least ipp2p does something like that. But
maybe thats not necessary, since l7filter already uses regexes
there's apparently a different method for doing this.

It would be useful if someone could post an excerpt from the
l7filter expressions or simply the entire patch.

> The other choise is userspace by means NFQUEUE. If we use some
> heuristics, we may try to classify the traffic by means of the initial
> data packets and then mark the connection. Thus, the number of packets
> that go to userspace would be small and the classification logic is
> implemented in userspace using whatever regex
> engine/aho-corasick/bit-wise/boyer-moore/bayes whatsoever...

Yes, thats another possibilty (and a lot of people are doing
that), but it would still be nice to have a mechanism for
doing this in the kernel.

Re: POM Xtables???

[James King]

(Sorry for the spam Patrick, I just realized that I didn't reply-all
the first time around)

On Thu, Jul 24, 2008 at 2:43 AM, Patrick McHardy <kaber@trash.net> wrote:
>> James King wrote:
>>> One thing
>>> I'm not sure of is whether the license used by the Henry Spencer regex
>>> library it depends on is acceptable by kernel standards (or whether
>>> it's permissive enough to relicense under GPL, as IANAL).
>
> I know of the regexp.old.zip library, which IIRC used a GPL
> compatible license (and a non-POSIX conform interface).
>
>> If we want to do this in-kernel I think that it's better if it must use
>> the textsearch infrastructure. Probably it would require some patches to
>> extend the existing infrastructure.
>
> I'd also prefer that over adding a regex library to the kernel.
> I think one of the bigger problems is that there are dependencies
> in the match that can't be easily expressed, like "byte 4 has
> skb->len - 10". At least ipp2p does something like that. But
> maybe thats not necessary, since l7filter already uses regexes
> there's apparently a different method for doing this.
>
> It would be useful if someone could post an excerpt from the
> l7filter expressions or simply the entire patch.

ipp2p and l7filter both use different strategies for DPI
classification, each having their own pros and cons.

ipp2p has the potential to classify traffic faster since it uses magic
values/offsets before moving on to more detailed searches.  As you
noted above, the match can also be a bit "deeper" since it can express
more complex relationships.  It's also better for memory usage, since
it doesn't store packet data.  The downside is poor configurability
and maintainability.

l7filter adds a buffer (default size of 2048 bytes, kmalloc'd on the
first packet of a flow, and freed after classification is complete) to
the conntrack and appends inbound and outbound packets into this
buffer (in the order received), up to a configurable number of packets
before giving up on classification.  It runs each configured regex
rule against this buffer in sequence, which can get very expensive
especially when you have a lot of matches or your patterns include a
lot of branches, since a large amount of search work is potentially
being duplicated by each rule.  However, being able to setup these
matches at runtime is what makes l7filter much more convenient to use
overall.

After reviewing the l7filter code a bit, I've found that it does some
nasty things at present like holding a BH spinlock over the entire
match function, and allocating a per-conntrack character buffer
containing the string name of the pattern that we've matched (eg.
http-audio, bittorrent, battlefield2, etc) for the entire life of the
conntrack.  Also, the work necessary to convert the backend to use
textsearch and still maintain compatibility with the existing patterns
seems a bit prohibitive at the moment.

I think the best thing to do for now is to move it into xtables-addons
(providing Jan has no objections) for further review and cleanup.
I've had a bit of time to work on this during my vacation, but I was
wondering if I could get some clarification on a couple things:
-Under what circumstances does it become mandatory to implement the
ct_extend move callback?
-The description from Krzystof's recent accounting patch (which btw
doesn't appear to have been merged during the last window after all)
notes:

"...newly created connections get additional acct extend.  Old
connections are not changed as it is not possible to add a ct_extend
area to confirmed conntrack"

His patch adds a call to nf_conntrack_acct_init() inside of
conntrack_init() to add the private area.  For an out of tree module,
obviously this isn't a good solution (I'd like to use this module
against a stock kernel if possible).  I suppose I could include
something like this near the beginning of the match function:

layer7 = nf_ct_ext_find(ct, NF_CT_EXT_LAYER7);
if (!layer7 && !nf_ct_is_confirmed(ct))
	ret = nf_ct_ext_add(ct, NF_CT_EXT_LAYER7, GFP_ATOMIC);

...but this seems kludgy.  Is there a better way of doing this?  If
not, maybe we could add an init callback to ct_extend (and basically
clone nf_ct_ext_destroy() and __nf_ct_ext_destroy()), and call it from
conntrack_init(), so any number of extensions can be added without
having to patch conntrack_init() each time.

-In the same thread of avoiding a kernel recompile, it would be great
if there was a way to add a new extension type on the fly, or at least
had one enumeration reserved for use by out of tree modules (eg.
NF_CT_EXT_RESERVED).  Any thoughts here?

Re: POM Xtables???

[Brent Clark]

James King wrote:
> ipp2p and l7filter both use different strategies for DPI
> classification, each having their own pros and cons.
You know most people, groups etc look for the next best thing. Take a 
look at Firefox and apple ( *pod), they continuously announcing whats 
hip and new, what they doing etc, and looking at ways to keep a captive 
audience.

My question is what netfilters next best thing?

Having used and using Xtables, I thinking it FSCKING brilliant (excuse 
slander, hope I did not offend, but there was not other way to explain). 
I dont have to struggle and my turn around time is minutes.
I continuously thank Jan for the work his doing.

I suggest forget POM. its old and the process is slow and laborious (and 
thats hoping you can get it compiled in the kernel).

Getting back to iptables.

Its great to see others stepping forward and wanting to implement a 
Layer 7 filtering, and I say go for it and work on it, but in the mean 
time and to the netfilter team, my question is, how long will that take 
till its able to get off the ground to too hope that it gets accepted by 
the teams (netfilter and kernel).

To be constructive, and looking for a solid way forward (even if 
interim), would it not be better to implement l7 in xtables or better 
iptables.
Yes the L7 code may suck now or incorrectly thoughtout, but getting it 
working will help people. People understand that its not perfect or bug 
less, the fact they have option and it being worked on, helps.

Im of the opinion that Netfilter really needs to look and think out the 
box and realize ppl want *now*, troubleless (less not free), shiny and 
new (this goes hand in hand with promoting, marketing etc).
Google for pf vs iptables, and you will find a plethora of links 
promoting either / or. Netfilter needs that "shiny" that will set it 
apart from the rest that will and have the bells and whistles.

My aim it to not offend anyone, but let the powers that be know, that 
there is a demand for more. Ill probably get flamed, but I hope this 
email gets taken in the light of constructive criticism and for the 
greater of the user community that like quick install, all in one solution.

Kind Regards
Brent Clark

P.s. James, I hope you get your solution off the ground  and working.

Re: POM Xtables???

[James King]

On Thu, Jul 24, 2008 at 2:21 AM, Pablo Neira Ayuso <pablo@netfilter.org> wrote:
> The other choise is userspace by means NFQUEUE. If we use some
> heuristics, we may try to classify the traffic by means of the initial
> data packets and then mark the connection. Thus, the number of packets
> that go to userspace would be small and the classification logic is
> implemented in userspace using whatever regex
> engine/aho-corasick/bit-wise/boyer-moore/bayes whatsoever...

I'm a bit nervous about using the existing mechanisms for userspace
classification.  As I understand it (and correct me if I'm wrong),
network performance could be severely impacted if the system load gets
high (packet is blocked until userspace returns a verdict?).  If so,
even restricting the number of packets going to userspace to the
initial exchange won't solve this problem.

Asynchronous userspace classification on the other hand could be
extremely useful.  If there was a mechanism to fire packets and their
associated conntrack ID to userspace and immediately allow the packet
through unmolested (so that userspace delays wouldn't hinder traffic),
combined with a way to set CONNMARK for an arbitrary conntrack from
userspace after the fact, this type of impact could be greatly
minimized.  The only drawback I can think of would be for very
short-lived flows, where the conntrack has already gone away by the
time userspace makes a decision.

Re: POM Xtables???

[Jozsef Kadlecsik]

Hi,

On Mon, 30 Jun 2008, Patrick McHardy wrote:

> History has repeatedly shown that out of tree patches are buggy
> and cause more problems than they solve, which is why there
> is no interest from the netfilter team in maintaining external
> patches (with the one exception of ipset, which is not considered
> ready for upstream yet by Jozsef, its author).

The reason why I haven't been considering ipset ready for kernel inclusion 
is actually simple: the current ipset framework is not flexible enough due 
to the rigid kernel<->userspace communication method and it does not 
support IPv6 at all. As I had expected to be ready with the next 
generation of ipset (codename nfset) more soon, I have been refraining to 
submit ipset for kernel inclusion. nfset is finally getting shape, by the 
end of summer it'll be released. So the reason not to submit ipset is 
stronger than ever.

In order to make life easier, as I apply the patches sent by Swen, 
there'll be a new, "standalone" version of ipset, i.e. it'll be possible 
to use it without patch-o-matic-ng.
 
Best regards,
Jozsef
-
E-mail  : kadlec@blackhole.kfki.hu, kadlec@mail.kfki.hu
PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : KFKI Research Institute for Particle and Nuclear Physics
          H-1525 Budapest 114, POB. 49, Hungary

Re: POM Xtables???

[Jan Engelhardt]

On Monday 2008-06-30 23:11, Jozsef Kadlecsik wrote:
>
>In order to make life easier, as I apply the patches sent by Swen, 
>there'll be a new, "standalone" version of ipset, i.e. it'll be possible 
>to use it without patch-o-matic-ng.

I have been tracking ipset a bit lately, it already seems
standing alone. Would you be willing to make it available
through Xtables-addons?
A test head for inspection can be found at
	git://dev.medozas.de/xtables-addons ipset

Re: POM Xtables???

[Jozsef Kadlecsik]

On Mon, 30 Jun 2008, Jan Engelhardt wrote:

> On Monday 2008-06-30 23:11, Jozsef Kadlecsik wrote:
> >
> >In order to make life easier, as I apply the patches sent by Swen, 
> >there'll be a new, "standalone" version of ipset, i.e. it'll be possible 
> >to use it without patch-o-matic-ng.
> 
> I have been tracking ipset a bit lately, it already seems
> standing alone. Would you be willing to make it available
> through Xtables-addons?
> A test head for inspection can be found at
> 	git://dev.medozas.de/xtables-addons ipset

The iptables match and target for ipset are in the iptables source tree, 
so that part is totally independent from pom-ng and supported by iptables, 
out of the box. As ipset is IPv4-only, there's no way to create an xtables
variant of the match and the target :-).

The source of the 'ipset' binary, which is totally independent from 
iptables or xtables, is currently in svn, but we can move it to git 
anytime. I don't really see what would be the benefit in adding ipset to 
xtables-addons, sorry. But thank you the offer!

Best regards,
Jozsef
-
E-mail  : kadlec@blackhole.kfki.hu, kadlec@mail.kfki.hu
PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : KFKI Research Institute for Particle and Nuclear Physics
          H-1525 Budapest 114, POB. 49, Hungary

Re: POM Xtables???

[Jan Engelhardt]

On Tuesday 2008-07-01 12:00, Jozsef Kadlecsik wrote:
>On Mon, 30 Jun 2008, Jan Engelhardt wrote:
>> On Monday 2008-06-30 23:11, Jozsef Kadlecsik wrote:
>> >
>> >In order to make life easier, as I apply the patches sent by Swen, 
>> >there'll be a new, "standalone" version of ipset, i.e. it'll be possible 
>> >to use it without patch-o-matic-ng.
>> 
>> I have been tracking ipset a bit lately, it already seems
>> standing alone. Would you be willing to make it available
>> through Xtables-addons?
>> A test head for inspection can be found at
>> 	git://dev.medozas.de/xtables-addons ipset
>
>The iptables match and target for ipset are in the iptables source tree, 

Well that won't impact is positively nor negatively. It has always
been that way, and whether people get libipt_{SET,set} through
iptables or the ipset tarball - it would not matter.

>so that part is totally independent from pom-ng and supported by iptables, 
>out of the box. As ipset is IPv4-only, there's no way to create an xtables
>variant of the match and the target :-).

Just because something is limited to IPv4 does not mean it is
not 'x' ('x' as in xtables). It is all just names, and getting it
under one unified hut is a good thing. In fact, onnnnnnnnce (;-)
I get around to submit the next patchsets, we will have xt modules
that have neither IPv4 nor IPv6 components.

>The source of the 'ipset' binary, which is totally independent from 
>iptables or xtables, is currently in svn, but we can move it to git 
>anytime. I don't really see what would be the benefit in adding ipset to 
>xtables-addons, sorry. But thank you the offer!

Benefits?
- removing 73% of all #ifdef kludges from *.c (the kernel files)
- less tarballs for users to build
- autoconf for the binary :-P

Re: POM Xtables???

[Jan Engelhardt]

On Monday 2008-06-30 18:04, Dave wrote:

>Over the weekend I managed to get the Xtables-addons working with
>Kernel 2.6.25.  Throughout this process many questions have come up
>that were unanswered by the documentation or Netfilter site.  I'll
>point them out.
>
>1) Confusion on just what Xtables is.  Is Xtables really just
>Iptables?  It seems to be, but there is nothing saying so officially.
>2) Is Xtables the same things as Xtables-addons, Jan in your
>directory, the files go from Xtables..... to Xtables-addons.... , does
>this mean they are the same thing or different?

I recently had updated http://en.wikipedia.org/wiki/Netfilter , maybe it gives
a few hints.

Xtables, is x_tables.ko, in other words, the firewall, and the table
structure as you know it. It is the mold of ip_tables.ko and
ip6_tables.ko, though of course the latter two still exist, for
reasons of simple "unsharability", code that applies to just one of
IPv4 or IPv6, respectively.

Sometimes people call it Iptables too, it has become synonymous. The
same holds true for the userspace tool. When in doubt, the suffix
"kernel components" or "userspace components" should be added when
mentioning xtables and/or iptables if we cannot figure out.

Hence xtables-addons. The name was strongly inspired by
asterisk-addons, actually.

>3) Still don't know where Xtables-addons fits in with Netfilter?  Why
>is Xtables not on the Netfilter site or even mentioned there at all?

It is a relatively new name that had not yet had much widespread use
(in the process of promoting it though); people still call iptables
and xtables interchangably. Xtables is not a completely shiny new
product, but a gradual evolution from previous code, so people see
less need to call it that way, especially since most of the users
only deal with the IPV4-specific part of the userspace tools anyway
(aka /usr/sbin/iptables).