Re: kernel helper modules parameters

[Mr Dash Four <mr.dash.four@googlemail.com>]

 

>> 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.