Re: kernel helper modules parameters
|[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]|
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!
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 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.
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.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.)
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