Bug 1169755 - iptables: Protocol wrong type for socket (regression, bisected)
Summary: iptables: Protocol wrong type for socket (regression, bisected)
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise MRG
Classification: Red Hat
Component: realtime-kernel
Version: 2.4
Hardware: x86_64
OS: Linux
unspecified
high
Target Milestone: 2.5.12
: ---
Assignee: Arnaldo Carvalho de Melo
QA Contact: MRG Quality Engineering
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-12-02 11:26 UTC by Jeremy Harris
Modified: 2019-05-20 11:22 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
An upstream patch removing the xt_connlimit revision zero ABI was not reverted on the kernel-rt package, which caused problems because the iptables package present in Red Hat releases requires this revision. This upstream patch to remove the xt_connlimit revision 0 was reverted from the kernel-rt sources to allow the iptables command to execute correctly on Red Hat Enterprise MRG.
Clone Of:
Environment:
Last Closed: 2015-03-17 14:41:13 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2015:0694 0 normal SHIPPED_LIVE Important: kernel-rt security, bug fix, and enhancement update 2015-03-17 18:39:44 UTC

Description Jeremy Harris 2014-12-02 11:26:58 UTC
Description of problem:
 Loading an iptables rule, error

Version-Release number of selected component (if applicable):
 3.10.33-rt32.32


How reproducible:
 100%

Steps to Reproduce:
1. boot
2. sudo iptables -A INPUT -p tcp --syn --dport 9120 -m connlimit --connlimit-above 500 -j REJECT --reject-with tcp-reset
3.

Actual results:
"iptables: Protocol wrong type for socket"


Expected results:
no output; rule added according to "iptables -L"


Additional info:

 Tested-good kernel: 3.2.33-rt50.66.el6rt.x86_64

 Broken behaviour appears at this commit:

 >commit 68c07cb6d8aa05daf38ab47d5bb674d81a2066fb
 >Author: Cong Wang <xiyou.wangcong>
 >Date:   Sat May 19 04:39:01 2012 +0000
 >
 >    netfilter: xt_connlimit: remove revision 0
 >
 >    It was scheduled to be removed.

 The same commit was made in the upstream tree (and was in v3.5) which was
 imported at the start of rhel7 development: 68c07cb
 - however the symptom does not show on a recent rhel7 kernel
 (kernel-3.10.0-201.el7)

 3.10 kernel works as far back as the upstream v3.10 tag.  I can't get a 3.9
 build that boots, so no info on that.

Comment 1 Arnaldo Carvalho de Melo 2015-01-12 20:34:03 UTC
Rule fails on 3.10.58-rt62.60.el6rt.x86_64, works on 
3.10.0-210.el7.x86_64, so problem reproduced here, trying to figure out what made it work again, as no obvious candidate patch on upstream was found by simple visual inspection.

Will look at the rhel6 git repository.

Comment 3 Arnaldo Carvalho de Melo 2015-01-20 15:56:55 UTC
It does not work all the way to 3.10.58-rt62.61.hotfix, because  xt_connlimit revision zero ABI was removed in the kernel and is still used by RHEL's iptables 1.4.7 package, we would need to go to 1.4.11 to have iptables using revision 1 to have it working. Reverting the revision 0 removal patch makes it works again without having to update  iptables.

Tested  by using that extension to establish a limit of 2 connections to TCP  port 22 (ssh) and having the 3rd ssh attempt into a machine with that  limit to fail, as intended.

Reverting 68c07cb6d8aa05daf38ab47d5bb674d81a2066fb conflicts with Documentation/feature-removal-schedule.txt, because that file was nuked by Linus, so when doing the:

git revert 68c07cb6d8aa05daf38ab47d5bb674d81a2066fb

Just do a 'git rm Documentation/feature-removal-schedule.txt"

and then:

git commit

Which I did with this comment:

-------------------
We need revision zero since on MRG/RHEL6 we have an iptables release that requires it.
-------------------

To test it, boot the resulting kernel, make sure no other iptables rule gets in the way, this is the big hammer for that:

iptables -F

Will flush all netfilter rules, then use iptables to test that xt_connlimit provides the revision 0 expected by it:

iptables -A INPUT -p tcp --syn --dport 22 -m connlimit --connlimit-above 2 -j REJECT --reject-with tcp-reset

No error messages should appear this time and doing:

[root@ssdandy ~]# iptables -L INPUT
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         
REJECT     tcp  --  anywhere             anywhere             tcp dpt:ssh flags:FIN,SYN,RST,ACK/SYN #conn src/32 > 2 reject-with tcp-reset
[root@ssdandy ~]#

Then try ssh'ing into that machine, the 3rd connection attempt will fail, as intended.

Comment 10 errata-xmlrpc 2015-03-17 14:41:13 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHSA-2015-0694.html


Note You need to log in before you can comment on or make changes to this bug.