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.
--
To unsubscribe from this list: send the line "unsubscribe netfilter" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
