Description of problem: iptables is reporting "Unknown error 18446744073709551615" when trying to use the conntrack module Version-Release number of selected component (if applicable): kernel 2.6.33.7-rt29.47 iptables v1.3.5 How reproducible: try to make use of the conntrack module Steps to Reproduce: 1. iptables --flush 2. iptables -A INPUT -p tcp --dport 20158 -m conntrack --ctstate NEW -m limit --limit 5/s -j LOG --log-prefix "cstate new: " OR 1. cat /proc/net/ip_conntrack Actual results: iptables: Unknown error 18446744073709551615 OR cat: /proc/net/ip_conntrack: No such file or directory Expected results: rule accepted OR list of tracked connections
tried on kernel-rt-2.6.24.7-149.el5rt and there conntrack module is not reporting these unknown errors
Could you please update iptables to version 1.3.5-5.3.el5_4.1 and repeat the test?
rpm -qa iptables iptables-1.3.5-5.3.el5_4.1 v1.3.5 was the output of iptables --version I've tried on many different boxes and the problem appear to be in here. Can anybody confirm or is something wrong with my setup?
I believe this issue is related to the issue fixed in bz521999 / bz520797 and not to your particular setup. In short, the new kernel uses a struct that slightly differs from the one used by this version of the iptables tool.
Thank you for your reply. I'm not into kernel hacking and I've no idea on how internal things work. Seeing those two tickets I assume I cannot fix it by myself but will have to wait either for a fixed kernel package or fixed iptables package? So, as for now, everybody running rhel/mrg 2.6.33 kernel branch cannot use ip conntrack? :| (the rule is not loaded into iptables: the export resulting from iptables-save does not contains it)
I suspect the fix will be an updated iptables package, since it's usually easier to update the user-space side of things than modify the kernel to match an older user-space. We'll need to decide if it's updated in RHEL5 or in MRG-RT. As a rule we don't carry duplicate packages in MRG-RT to avoid the confusion factor.
As a quickfix, you can try to use the state module instead of the conntrack module. Just replace -m conntrack with -m state and --ctstate with --state [root@host ~]# iptables -A INPUT -p tcp --dport 20158 -m state --state NEW -m limit --limit 5/s -j LOG --log-prefix "state new: " I've tested the state module, and it seems to work just fine in this situation. We are still looking into how to make iptables and the newer kernel base (2.6.33) work together better. A lot has happened in the netfilter parts of the kernel, which have broken some of the features, like conntrack.
thanks for the reply. yeah, I did that in the meantime... the problem that on all the boxes I manage conntrack was doing fine... and managing a single ruleset was simplier.. ;) anyhow another thing reporting strange errors is the "recent" module... iptables -A RANDOM -m recent --update --name RANDOMCOUNTER --seconds 20 --hitcount 1 -j DROP with parameters like: "--seconds 20 --hitcount 1" it's accepted... but when trying something like: "--seconds 200 --hitcount 50" it was failing... basically it was failing with any hitcount above 40 IIRC (I should retry/search for the logs)... the failure was reported with an error similar to the one posted here in this bug report... I think it's another related problem...
(In reply to comment #8) > thanks for the reply. > > yeah, I did that in the meantime... the problem that on all the boxes I manage > conntrack was doing fine... and managing a single ruleset was simplier.. ;) Agreed! And we are still working on a solution to avoid this in the future. > anyhow another thing reporting strange errors is the "recent" module... > > iptables -A RANDOM -m recent --update --name RANDOMCOUNTER --seconds 20 > --hitcount 1 -j DROP > > with parameters like: "--seconds 20 --hitcount 1" it's accepted... > > but when trying something like: > "--seconds 200 --hitcount 50" > > it was failing... basically it was failing with any hitcount above 40 IIRC (I > should retry/search for the logs)... > > the failure was reported with an error similar to the one posted here in this > bug report... I think it's another related problem... This is a completely another issue. On my test box, I am able to see this error as well. However, that is (code wise) a different issue, as it is another iptables module. I believe that should be tracked in a separate bug. So if you still have problems with this, and it does not fail under the normal RHEL (2.6.18 based) kernel - please create a new bugzilla against the realtime-kernel. Otherwise this is more likely to be an iptables or RHEL kernel bug too.
MRG-1 on Red Hat Enterprise Linux 5 reached it's end of life on March 31, 2014. Because this issue is against the MRG-1 release, we are closing it WONTFIX. If you believe this is still an issue on our most recent MRG-2.5 3.10 kernel, please file a new issue for tracking.