Bug 667679

Summary:	missing iptables conntrack support?
Product:	Red Hat Enterprise MRG	Reporter:	evcz
Component:	realtime-kernel	Assignee:	Luis Claudio R. Goncalves <lgoncalv>
Status:	CLOSED WONTFIX	QA Contact:	David Sommerseth <davids>
Severity:	high	Docs Contact:
Priority:	medium
Version:	1.3	CC:	bhu, lgoncalv, ovasik, williams
Target Milestone:	---
Target Release:	---
Hardware:	x86_64
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2014-08-19 20:44:01 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description evcz 2011-01-06 13:27:19 UTC

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

Comment 1 evcz 2011-01-10 13:28:30 UTC

tried on kernel-rt-2.6.24.7-149.el5rt and there conntrack module is not reporting these unknown errors

Comment 2 Luis Claudio R. Goncalves 2011-01-11 13:26:11 UTC

Could you please update iptables to version 1.3.5-5.3.el5_4.1 and repeat the test?

Comment 3 evcz 2011-01-11 13:30:10 UTC

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?

Comment 4 Luis Claudio R. Goncalves 2011-01-11 13:41:48 UTC

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.

Comment 5 evcz 2011-01-11 13:53:09 UTC

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)

Comment 6 Clark Williams 2011-01-11 20:44:17 UTC

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.

Comment 7 David Sommerseth 2011-01-18 15:58:54 UTC

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.

Comment 8 evcz 2011-01-18 22:46:06 UTC

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

Comment 9 David Sommerseth 2011-01-19 06:25:48 UTC

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

Comment 10 Beth Uptagrafft 2014-08-19 20:44:01 UTC

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.