kernel helper modules parameters

kernel helper modules parameters

[Mr Dash Four]

Is there a definite list/doc/man page describing the parameters which 
can be used when loading/configuring these modules?

I would like to do some testing with the (t)ftp, sip, h323 and possibly 
netbios_ns module helpers. I am most definitely not going to use the 
standard ports these protocols operate on, so need to know, among other 
things, how can I reconfigure the helpers and the degree of leverage I 
have (i.e. what I can/cannot get away with). Thanks.

Re: kernel helper modules parameters

[Mr Dash Four]

> I would like to do some testing with the (t)ftp, sip, h323 and 
> possibly netbios_ns module helpers. I am most definitely not going to 
> use the standard ports these protocols operate on, so need to know, 
> among other things, how can I reconfigure the helpers and the degree 
> of leverage I have (i.e. what I can/cannot get away with). Thanks.
-bash~# ipset n test hash:ip family inet timeout 0 hashsize 128
-bash~# ipset a test 10.99.99.1
-bash~# iptables -A OUTPUT -t raw -p tcp --dport 17021 -m set 
--match-set test dst -j CT --helper ftp
-bash~# iptables -t raw -L OUTPUT -vn
Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               
destination        
    0     0 CT         tcp  --  *      *       0.0.0.0/0            
0.0.0.0/0           tcp dpt:17021 match-set test dst CT helper ftp
-bash~# iptables -D OUTPUT -t raw -p tcp --dport 17021 -m set 
--match-set test dst -j CT --helper ftp
-bash~# ipset x test
-bash~# ipset n test hash:ip,port family inet timeout 0 hashsize 128
ipset a test 10.99.99.1,tcp:17021
-bash~# iptables -A OUTPUT -t raw -m set --match-set test dst,dst -j CT 
--helper ftp
*iptables: No chain/target/match by that name.*
-bash~# iptables -A OUTPUT -t raw -p tcp -m set --match-set test dst,dst 
-j CT --helper ftp
-bash~# iptables -t raw -L OUTPUT -vn
Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               
destination        
    0     0 CT         tcp  --  *      *       0.0.0.0/0            
0.0.0.0/0           match-set test dst,dst CT helper ftp
-bash~# iptables -A OUTPUT -t raw -p udp -m set --match-set test dst,dst 
-j CT --helper ftp
*iptables: No chain/target/match by that name.*

Anyone kind enough to enlighten me why do I have to specify a protocol 
(which matches the ipset type exactly!) in order for iptables to accept 
and create that rule? For the filter table there is no such constraint.

Re: kernel helper modules parameters

[Jan Engelhardt]

On Wednesday 2012-02-08 04:11, Mr Dash Four wrote:

>
>> I would like to do some testing with the (t)ftp, sip, h323 and possibly
>> netbios_ns module helpers. I am most definitely not going to use the standard
>> ports these protocols operate on, so need to know, among other things, how can
>> I reconfigure the helpers and the degree of leverage I have (i.e. what I
>> can/cannot get away with). Thanks.

> -bash~# ipset n test hash:ip family inet timeout 0 hashsize 128
> -bash~# ipset a test 10.99.99.1

tl;dr: What does ipset have to do with the tftp/sip/h323 conntrack 
modules?

Re: kernel helper modules parameters

[Mr Dash Four]

> tl;dr: What does ipset have to do with the tftp/sip/h323 conntrack 
> modules?
>   
Are you really *that* thick?

Re: kernel helper modules parameters

[Jan Engelhardt]

On Wednesday 2012-02-08 04:59, Mr Dash Four wrote:

>
>> tl;dr: What does ipset have to do with the tftp/sip/h323 conntrack modules?
>>  
> Are you really *that* thick?

Yes, apparently my other self was sleep-walking and missed the -j CT.

>-bash~# iptables -A OUTPUT -t raw -p udp -m set --match-set test
>dst,dst -j CT --helper ftp
>iptables: No chain/target/match by that name.
>                                                                                
>Anyone kind enough to enlighten me why do I have to specify a protocol          
>(which matches the ipset type exactly!) in order for iptables to accept and     
>create that rule? For the filter table there is no such constraint.             

ENOENT is traditionally returned by x_tables when a
chain/target/match could not be found and hence ENOENT has been
largely tied to the very translation ("No chain/target/match by that
name") that you see. Looking at xt_set.c reveals that xt_set, too,
can return -ENOENT from its checkentry function, which x_tables just
passed up to userspace. Hence there is no way to distinguish between
the two. However, xt_set also emits a message into dmesg via
pr_warning when it does return ENOENT.

The ip_set_nfnl_get_byindex function returning ENOENT would in turn
indicate that there was no set by the given index, which I gather
must have been translated from the set name in userspace already.
It is possible that this set is removed between the time the lookup was 
done and that the rule reached the kernel. And that is unlikely.

>-bash~# ipset n test hash:ip,port family inet timeout 0 hashsize 128
><Not run:: ipset a test 10.99.99.1,tcp:17021>
>-bash~# iptables -A OUTPUT -t raw -m set --match-set test dst,dst -j CT
>--helper ftp
>iptables: No chain/target/match by that name.

Given that

# ipset n test hash:ip,port family inet timeout 0 hashsize 128
# iptables -A OUTPUT -t raw -m set --match-set test dst,dst

succeeds, and adding -j CT does not (and I know I do have xt_CT),
dmesg is once again handy:

[29710.653372] xt_CT: You must specify a L4 protocol, and not use inversions on
it.

(And yes, xt_CT also returns ENOENT. Guess we need to change
the error message that the iptables frontend prints.)

hth.

Re: kernel helper modules parameters

[Mr Dash Four]

 

>> Are you really *that* thick?
>>     
>
> Yes, apparently my other self was sleep-walking and missed the -j CT.
>   
It is never a good idea to work long hours!

> ENOENT is traditionally returned by x_tables when a
> chain/target/match could not be found and hence ENOENT has been
> largely tied to the very translation ("No chain/target/match by that
> name") that you see. Looking at xt_set.c reveals that xt_set, too,
> can return -ENOENT from its checkentry function, which x_tables just
> passed up to userspace. Hence there is no way to distinguish between
> the two. However, xt_set also emits a message into dmesg via
> pr_warning when it does return ENOENT.
>
> The ip_set_nfnl_get_byindex function returning ENOENT would in turn
> indicate that there was no set by the given index, which I gather
> must have been translated from the set name in userspace already.
> It is possible that this set is removed between the time the lookup was 
> done and that the rule reached the kernel. And that is unlikely.
>   
You need to bear in mind that my understanding of the internal netfilter 
intricacies is still a bit limited, so you have to translate the above 
for the "regular" folk like myself.

> Given that
>
> # ipset n test hash:ip,port family inet timeout 0 hashsize 128
> # iptables -A OUTPUT -t raw -m set --match-set test dst,dst
>
> succeeds, and adding -j CT does not (and I know I do have xt_CT),
> dmesg is once again handy:
>
> [29710.653372] xt_CT: You must specify a L4 protocol, and not use inversions on
> it.
>
> (And yes, xt_CT also returns ENOENT. Guess we need to change
> the error message that the iptables frontend prints.)
>   
I forgot to look at dmesg/syslog - indeed, I do have the same message (a 
couple of times). What I can't understand is why do I have to specify a 
protocol when ipset can match on IP address & port/protocol at the same 
time (that is the sole purpose of hash:ip,port isn't it?)? The "L4 
protocol" is already specified when the set members are registered in 
that set, so I don't see any need to include the protocol part in the 
iptables statement.

One other thing, which may cause further complications - the ftp helper 
is supposed to work on tcp protocol only, so in theory, I should not be 
allowed to register anything other than that protocol. I suspect if I 
try to register udp (or any other protocol which differs from tcp) I 
will succeed. So, I think, this may need to be corrected as well.

Re: kernel helper modules parameters

[Jan Engelhardt]

On Wednesday 2012-02-08 15:19, Mr Dash Four wrote:
>> ENOENT is traditionally returned by x_tables [...]
>> The ip_set_nfnl_get_byindex function returning ENOENT[...]
>>  
> You need to bear in mind that my understanding of the internal netfilter
> intricacies is still a bit limited, so you have to translate the above for the
> "regular" folk like myself.

"ENOENT has many meanings, and iptables prints just one of them,
which is potentially misleading."

>> [29710.653372] xt_CT: You must specify a L4 protocol, and not use inversions
>> on it.
>
>why do I have to specify a protocol when ipset can match on IP address &
>port/protocol at the same time (that is the sole purpose of hash:ip,port
>isn't it?)? The "L4 protocol" is already specified when the set members
>are registered in that set.

The message is output by CT, not ipset. Extensions are independent
and isolated, and have no knowledge of one another's existence or
inner workings.

The reason you have to specify -p tcp is so that CT can take a
reference to the particular helper instance (which is identified
by name, L3 family, _and_ L4 family) and/or load a module that
does provide such instances, respectively.

For example, attempting to do -p sctp -j CT --helper ftp should fail,
because there is no helper instace (nor a module in the default
kernel to provide such). - In other words, nf_conntrack_ftp only
knows to deal with TCP.

While we do know whata L4 protocol a packet is once it is received
from the network, there is no chance to load the required module
on the fly due to interrupt context constraint, so hypothetically
allowing "(-p all) -j CT" would be unreliable, packets would not
"get helped".

As such, specify the L4 beforehand is a requirement.

> One other thing, which may cause further complications - the ftp helper is
> supposed to work on tcp protocol only, so in theory, I should not be allowed to
> register anything other than that protocol. I suspect if I try to register udp
> (or any other protocol which differs from tcp) I will succeed. So, I think,
> this may need to be corrected as well.

Precisely. "-p all" just is not the same as "-p tcp". I guess
one /could/ add a PF_UNSPEC instance to nf_conntrack_ftp.c,
thereby allowing to use -j CT without any -p (or nonsensical values
for -p) and ignore all packets that are not TCP.

But that would cause some practical overhead as a packet's verdict
would not be known until the helper code is executed. (Currently
the check can be done outside the helper because the L4 is
known in advance.)

Re: kernel helper modules parameters

[Mr Dash Four]

> "ENOENT has many meanings, and iptables prints just one of them,
> which is potentially misleading."
>   
Thanks, this will be corrected I take it?

> The reason you have to specify -p tcp is so that CT can take a
> reference to the particular helper instance (which is identified
> by name, L3 family, _and_ L4 family) and/or load a module that
> does provide such instances, respectively.
>   
Is there a need for the L4 inclusion (seems that it causes the initial 
error message)?

Also, there are helpers (the sip one comes to mind) that work both with 
tcp and udp protocols and are potentially great candidates to be used 
with the two-dimensional ipsets (hash:ip,port). As it stands though, I 
have to create two iptables statements *and* use one-dimensional ipset 
to load and use that particular helper. Wouldn't it be easier if the L4 
restriction is dropped/amended (if it is indeed the source of that 
error) so that protocols could be omitted when using two-dimensional sets?

> While we do know whata L4 protocol a packet is once it is received
> from the network, there is no chance to load the required module
> on the fly due to interrupt context constraint, so hypothetically
> allowing "(-p all) -j CT" would be unreliable, packets would not
> "get helped".
>
> As such, specify the L4 beforehand is a requirement.
>   
I thought the helper module is loaded once the iptables statement is 
created, isn't that the case? Also, if the helper itself allows for "-p 
all" (or "-p tcp" or "-p udp" at the very least) what then? The "L4 
protocol" restriction won't be needed, would it?

To me it seems rather unnecessary to have to specify a protocol where I 
could have ipset take care of that, otherwise I am left with the 
alternative of using one-dimensional sets only (I haven't yet tested the 
iface-type sets, so I strongly suspect I may have a bumpy ride there as 
well).

> Precisely. "-p all" just is not the same as "-p tcp". I guess
> one /could/ add a PF_UNSPEC instance to nf_conntrack_ftp.c,
> thereby allowing to use -j CT without any -p (or nonsensical values
> for -p) and ignore all packets that are not TCP.
>
> But that would cause some practical overhead as a packet's verdict
> would not be known until the helper code is executed. (Currently
> the check can be done outside the helper because the L4 is
> known in advance.)
>   
What I still can't get my head around yet is why the hesitation for not 
using a helper module, which was already specified (and I suspect loaded 
in memory) in the iptables statement - is there a concern that more than 
one module may be used for a particular packet? If that is so, then I 
could easily prepare a clash with using an ftp helper module selecting 
the same ip:protocol:port triplet for, say, ftp helper module as well as 
sip. What happens then?

On a side note, looking at Eric's "helper-recommandation.pdf" (I guess, 
I should have spell-checked the name of that file as well), as far as I 
understand it, there are two different methods of 
loading/creating/setting up helper modules:

1. Using the "FORWARD" chain in filter as well as specifying "RELATED" 
and helper name matches;
2. Using the PREROUTING/OUTPUT chain in raw by specifying the CT target 
with a helper name match (this is what I used in my examples up to now).

Are the two methods above interchangeable (i.e. use one or the other, 
but not both) or should I configure both (in which case I haven't tried 
my ipset trick using the first scenario!)? In that file there is no 
indication whether I should use one or the other (or both!).

If I have to use the first method above as well, why is the "FORWARD" 
chain used (at least in the examples given in that article)? If I want 
to set up a helper on outgoing packets then using the OUTPUT chain in 
filter seems to be the best solution.

I also take it either of the above methods is the preferred option 
instead of using modprobe (and force the loading of that helper module). 
Am I correct in thinking that?

Re: kernel helper modules parameters

[Jan Engelhardt]

On Wednesday 2012-02-08 16:16, Mr Dash Four wrote:

>
>> "ENOENT has many meanings, and iptables prints just one of them,
>> which is potentially misleading."
>>  
> Thanks, this will be corrected I take it?

Is this wording compatible enough with non-developers? :)

diff --git a/libiptc/libiptc.c b/libiptc/libiptc.c
index 42d9784..4106afe 100644
--- a/libiptc/libiptc.c
+++ b/libiptc/libiptc.c
@@ -2730,7 +2730,10 @@ TC_STRERROR(int err)
 	    { NULL, ENOPROTOOPT, "iptables who? (do you need to insmod?)" },
 	    { NULL, ENOSYS, "Will be implemented real soon.  I promise ;)" },
 	    { NULL, ENOMEM, "Memory allocation problem" },
-	    { NULL, ENOENT, "No chain/target/match by that name" },
+	    { NULL, ENOENT, "An object was not found. Check that the chain, "
+	                    "target/match extension, and/or per-extension "
+	                    "named object exists. Look at `dmesg` for "
+	                    "reports about the latter." },
 	  };
 
 	for (i = 0; i < sizeof(table)/sizeof(struct table_struct); i++) {

>>The reason you have to specify -p tcp is so that CT can take a
>>reference to the particular helper instance (which is identified
>>by name, L3 family, _and_ L4 family) and/or load a module that
>>does provide such instances, respectively.
>  
>Is there a need for the L4 inclusion (seems that it causes the initial error
>message)?


I guess this is a relic of the past. Before we had the CT target, the 
only way to assign packets to a helper was by port number.

Without the L4proto number being part of what uniquely identifies a 
helper instance (struct nf_conntrack_helper), you would not have been 
able to have both a RFC959-compatible helper listening on 21/tcp and a 
$my_own_fancy_protocol-understanding helper on 21/udp.

With CT, this now looks moot to me like it does to you, since packets 
can now be assigned via the awesome iptables logic, and the 
nf_conntrack_tuple inside struct nf_conntrack_helper basically goes 
unused.

Let's hear what Pablo (cc'd) has to say.

Re: kernel helper modules parameters

[Mr Dash Four]

> Is this wording compatible enough with non-developers? :)
>   
Well, actually, I *am* a developer! As I already pointed out, it is just 
that I am not that knowledgeable of the inner workings of netfilter (yet!).

> +	    { NULL, ENOENT, "An object was not found. Check that the chain, "
>   
"Object not found" perhaps?

> +	                    "target/match extension, and/or per-extension "
> +	                    "named object exists. Look at `dmesg` for "
> +	                    "reports about the latter." },
>   
In some circumstances (well, at least in my case anyway) the same 
message is also shown in the syslog, so you might want to add this as 
well - just in case you have somebody screaming in your ear why that 
wasn't included/provisioned or why is it that they "can't see anything 
in dmesg".

> With CT, this now looks moot to me like it does to you, since packets 
> can now be assigned via the awesome iptables logic, and the 
> nf_conntrack_tuple inside struct nf_conntrack_helper basically goes 
> unused.
>   
Yep, I agree - force-inclusion of the protocol seems unnecessary, 
particularly when you take into account that in the future there could 
be more helpers implementing variety of protocols (not just tcp/udp) 
and, as it stands, I have to create a separate statement for each - 
doesn't really make sense when ipset can handle this quite easily.

> Let's hear what Pablo (cc'd) has to say.
>   
I am all ears!

> 1. Using the "FORWARD" chain in filter as well as specifying "RELATED" 
> and helper name matches;
> 2. Using the PREROUTING/OUTPUT chain in raw by specifying the CT 
> target with a helper name match (this is what I used in my examples up 
> to now).
>
> Are the two methods above interchangeable (i.e. use one or the other, 
> but not both) or should I configure both (in which case I haven't 
> tried my ipset trick using the first scenario!)? In that file there is 
> no indication whether I should use one or the other (or both!).
>
> If I have to use the first method above as well, why is the "FORWARD" 
> chain used (at least in the examples given in that article)? If I want 
> to set up a helper on outgoing packets then using the OUTPUT chain in 
> filter seems to be the best solution.
>
> I also take it either of the above methods is the preferred option 
> instead of using modprobe (and force the loading of that helper 
> module). Am I correct in thinking that?
Any opinion on this?

Re: kernel helper modules parameters

[Pablo Neira Ayuso]

On Wed, Feb 08, 2012 at 04:49:07PM +0100, Jan Engelhardt wrote:
> On Wednesday 2012-02-08 16:16, Mr Dash Four wrote:
> 
> >
> >> "ENOENT has many meanings, and iptables prints just one of them,
> >> which is potentially misleading."
> >>  
> > Thanks, this will be corrected I take it?
> 
> Is this wording compatible enough with non-developers? :)
> 
> diff --git a/libiptc/libiptc.c b/libiptc/libiptc.c
> index 42d9784..4106afe 100644
> --- a/libiptc/libiptc.c
> +++ b/libiptc/libiptc.c
> @@ -2730,7 +2730,10 @@ TC_STRERROR(int err)
>  	    { NULL, ENOPROTOOPT, "iptables who? (do you need to insmod?)" },
>  	    { NULL, ENOSYS, "Will be implemented real soon.  I promise ;)" },
>  	    { NULL, ENOMEM, "Memory allocation problem" },
> -	    { NULL, ENOENT, "No chain/target/match by that name" },
> +	    { NULL, ENOENT, "An object was not found. Check that the chain, "
> +	                    "target/match extension, and/or per-extension "
> +	                    "named object exists. Look at `dmesg` for "
> +	                    "reports about the latter." },

This makes sense to me.

We still need better (more fine grain) error reporting though. That's
one limitation that would be great to solve.

Probably the netlink interface will allow us to solve this.

>  	  };
>  
>  	for (i = 0; i < sizeof(table)/sizeof(struct table_struct); i++) {
> 
> >>The reason you have to specify -p tcp is so that CT can take a
> >>reference to the particular helper instance (which is identified
> >>by name, L3 family, _and_ L4 family) and/or load a module that
> >>does provide such instances, respectively.
> >  
> >Is there a need for the L4 inclusion (seems that it causes the initial error
> >message)?
> 
> 
> I guess this is a relic of the past. Before we had the CT target, the 
> only way to assign packets to a helper was by port number.
> 
> Without the L4proto number being part of what uniquely identifies a 
> helper instance (struct nf_conntrack_helper), you would not have been 
> able to have both a RFC959-compatible helper listening on 21/tcp and a 
> $my_own_fancy_protocol-understanding helper on 21/udp.
> 
> With CT, this now looks moot to me like it does to you, since packets 
> can now be assigned via the awesome iptables logic, and the 
> nf_conntrack_tuple inside struct nf_conntrack_helper basically goes 
> unused.
> 
> Let's hear what Pablo (cc'd) has to say.

I think we can get rid of it once we remove the current conntrack
helper behaviour. We've discussed this before, and after Eric report
on the correct use of the conntrack helper, we need to make them fully
configurable through iptables, not through kernel module parameters.

Still, __nf_conntrack_helper_find seems to require the layer 4
protocol to look up for the helper if the CT target is not used (ie.
the default helper behaviour that we had since the very beginning).

We can plan to send a patch to warn that helper default behaviour is
deprecated in favour of the CT target, and that it will be removed
soon. Then, remove it in the near future (couple of years or so...).

Re: kernel helper modules parameters

[Jan Engelhardt]

On Monday 2012-02-13 10:06, Pablo Neira Ayuso wrote:

>On Wed, Feb 08, 2012 at 04:49:07PM +0100, Jan Engelhardt wrote:
>> On Wednesday 2012-02-08 16:16, Mr Dash Four wrote:
>> 
>> >
>> >> "ENOENT has many meanings, and iptables prints just one of them,
>> >> which is potentially misleading."
>> >>  
>> > Thanks, this will be corrected I take it?
>> 
>> Is this wording compatible enough with non-developers? :)
>> 
>> diff --git a/libiptc/libiptc.c b/libiptc/libiptc.c
>> index 42d9784..4106afe 100644
>> --- a/libiptc/libiptc.c
>> +++ b/libiptc/libiptc.c
>> @@ -2730,7 +2730,10 @@ TC_STRERROR(int err)
>>  	    { NULL, ENOPROTOOPT, "iptables who? (do you need to insmod?)" },
>>  	    { NULL, ENOSYS, "Will be implemented real soon.  I promise ;)" },
>>  	    { NULL, ENOMEM, "Memory allocation problem" },
>> -	    { NULL, ENOENT, "No chain/target/match by that name" },
>> +	    { NULL, ENOENT, "An object was not found. Check that the chain, "
>> +	                    "target/match extension, and/or per-extension "
>> +	                    "named object exists. Look at `dmesg` for "
>> +	                    "reports about the latter." },
>
>This makes sense to me.
>
>We still need better (more fine grain) error reporting though. That's
>one limitation that would be great to solve.
>
>Probably the netlink interface will allow us to solve this.

Yes. Did you see my most recent answer yet?:
http://marc.info/?l=netfilter-devel&m=132705156805852&w=2

Re: kernel helper modules parameters

[Pablo Neira Ayuso]

On Mon, Feb 13, 2012 at 10:38:53AM +0100, Jan Engelhardt wrote:
> On Monday 2012-02-13 10:06, Pablo Neira Ayuso wrote:
> 
> >On Wed, Feb 08, 2012 at 04:49:07PM +0100, Jan Engelhardt wrote:
> >> On Wednesday 2012-02-08 16:16, Mr Dash Four wrote:
> >> 
> >> >
> >> >> "ENOENT has many meanings, and iptables prints just one of them,
> >> >> which is potentially misleading."
> >> >>  
> >> > Thanks, this will be corrected I take it?
> >> 
> >> Is this wording compatible enough with non-developers? :)
> >> 
> >> diff --git a/libiptc/libiptc.c b/libiptc/libiptc.c
> >> index 42d9784..4106afe 100644
> >> --- a/libiptc/libiptc.c
> >> +++ b/libiptc/libiptc.c
> >> @@ -2730,7 +2730,10 @@ TC_STRERROR(int err)
> >>  	    { NULL, ENOPROTOOPT, "iptables who? (do you need to insmod?)" },
> >>  	    { NULL, ENOSYS, "Will be implemented real soon.  I promise ;)" },
> >>  	    { NULL, ENOMEM, "Memory allocation problem" },
> >> -	    { NULL, ENOENT, "No chain/target/match by that name" },
> >> +	    { NULL, ENOENT, "An object was not found. Check that the chain, "
> >> +	                    "target/match extension, and/or per-extension "
> >> +	                    "named object exists. Look at `dmesg` for "
> >> +	                    "reports about the latter." },
> >
> >This makes sense to me.
> >
> >We still need better (more fine grain) error reporting though. That's
> >one limitation that would be great to solve.
> >
> >Probably the netlink interface will allow us to solve this.
> 
> Yes. Did you see my most recent answer yet?:
> http://marc.info/?l=netfilter-devel&m=132705156805852&w=2

Yes, I read it.

Am I missing anything about it regarding this thread?

Re: kernel helper modules parameters

[Jan Engelhardt]

On Tuesday 2012-02-14 01:24, Pablo Neira Ayuso wrote:

>On Mon, Feb 13, 2012 at 10:38:53AM +0100, Jan Engelhardt wrote:
>> On Monday 2012-02-13 10:06, Pablo Neira Ayuso wrote:
>> 
>> >On Wed, Feb 08, 2012 at 04:49:07PM +0100, Jan Engelhardt wrote:
>> >> On Wednesday 2012-02-08 16:16, Mr Dash Four wrote:
>> >> 
>> >> >
>> >> >> "ENOENT has many meanings, and iptables prints just one of them,
>> >> >> which is potentially misleading."
>> >> >>  
>> >> > Thanks, this will be corrected I take it?
>> >> 
>> >> Is this wording compatible enough with non-developers? :)
>> >> 
>> >> diff --git a/libiptc/libiptc.c b/libiptc/libiptc.c
>> >> index 42d9784..4106afe 100644
>> >> --- a/libiptc/libiptc.c
>> >> +++ b/libiptc/libiptc.c
>> >> @@ -2730,7 +2730,10 @@ TC_STRERROR(int err)
>> >>  	    { NULL, ENOPROTOOPT, "iptables who? (do you need to insmod?)" },
>> >>  	    { NULL, ENOSYS, "Will be implemented real soon.  I promise ;)" },
>> >>  	    { NULL, ENOMEM, "Memory allocation problem" },
>> >> -	    { NULL, ENOENT, "No chain/target/match by that name" },
>> >> +	    { NULL, ENOENT, "An object was not found. Check that the chain, "
>> >> +	                    "target/match extension, and/or per-extension "
>> >> +	                    "named object exists. Look at `dmesg` for "
>> >> +	                    "reports about the latter." },
>> >
>> >This makes sense to me.
>> >
>> >We still need better (more fine grain) error reporting though. That's
>> >one limitation that would be great to solve.
>> >
>> >Probably the netlink interface will allow us to solve this.
>> 
>> Yes. Did you see my most recent answer yet?:
>> http://marc.info/?l=netfilter-devel&m=132705156805852&w=2
>
>Yes, I read it.
>
>Am I missing anything about it regarding this thread?

Well I then take it you were fine with the series of 7, and will build 
only patches on top.