| Anonymous | Login | Signup for a new account | 2013-05-23 21:07 MDT |
| Main | My View | View Issues | Change Log | Roadmap | Docs |
| Viewing Issue Simple Details [ Jump to Notes ] | [ View Advanced ] [ Issue History ] [ Print ] | ||||||
| ID | Category | Severity | Reproducibility | Date Submitted | Last Update | ||
| 0000097 | [channel: elrepo/el5] --elrepo--request-for-enhancement-- | major | always | 2010-12-08 03:49 | 2010-12-22 11:01 | ||
| Reporter | wolfy | View Status | public | ||||
| Assigned To | burakkucat | ||||||
| Priority | normal | Resolution | not fixable | ||||
| Status | closed | ||||||
| Summary | 0000097: kernel-ml lacks support for several targets accepted by kernel-2.6.18 from CentOS 5 / RHEL 5 | ||||||
| Description |
The following iptables modules are available in stock CentOS 5 kernel but are not included in kernel-ml-2.6.36-1.el5.elrepo: < ipt_DSCP.ko < ipt_SAME.ko < ipt_TCPMSS.ko < ipt_TOS.ko < ipt_TTL.ko < ipt_dscp.ko < ipt_hashlimit.ko < ipt_iprange.ko < ipt_owner.ko < ipt_recent.ko < ipt_tos.ko < ipt_ttl.ko If possible, please provide them. |
||||||
| Additional Information |
My firewall includes the following rules which are not usable with ELRepo's kernel-ml: iptables -A OUTPUT -o eth0 -m state --state NEW -d ! sw-share -m owner --uid-owner user3 -j REJECT --reject-with icmp-port-unreachable -A INPUT -p tcp -m tcp --dport 22 -m state --state NEW -j SSHSCAN iptables -A SSHSCAN -m recent --set --name SSH --rsource iptables -A SSHSCAN -m recent --update --seconds 900 --hitcount 5 --name SSH --rsource -j DROP |
||||||
| Tags | No tags attached. | ||||||
| Attached Files |
|
||||||
|
|
|||||||
Notes |
|
|
(0000431) wolfy (updater) 2010-12-08 03:57 |
/me dumb. sorry for the noise. I've forgotten about the xt vs ipt difference. please close this as NOTABUG |
|
(0000432) pperry (administrator) 2010-12-08 05:15 |
No problem Wolfy :-) |
|
(0000433) pperry (administrator) 2010-12-08 05:37 edited on: 2010-12-08 17:45 |
Added from #elrepo IRC: <wolfy> NedSlider: however an issue does exist <wolfy> NedSlider: stock iptables does not work well with new kernel <NedSlider> ok, understandable I guess <wolfy> [root@synps-ca ~]# iptables -A OUTPUT -o eth0 -m state --state NEW -d ! sw-share -m owner --uid-owner synopsys3 -j REJECT --reject-with icmp-port-unreachable <wolfy> iptables: Unknown error 4294967295 <NedSlider> we are finding issues with trying to shoehorn a new kernel into an aging distro * wolfy trying to test with iptables-1.4.7-3.el6. <NedSlider> which elrepo kernel is that? <wolfy> -ml-2.6.36-1 <NedSlider> thanks <NedSlider> I'll forward to Alan as kernel-ml is his domain :-) <wolfy> I would have been very surprised if the old iptables worked <wolfy> I had a looooot of issues back in the era when I used to compile my "optimized" kernels <wolfy> which included stuff from p-o-m <NedSlider> does basic iptables functionality work? is it just some of the more uncommon modules that break <wolfy> some work, some do not. I did not do exhaustive tests <wolfy> BUT there is a big problem <NedSlider> ok, thanks <wolfy> iptables-restore does not load any rule if anything from sysconfig/iptables fails <wolfy> and since I had a dozen or so offending rules (see the set from the bug report), I was faced with having no firewall loaded at all <wolfy> iptables-restore simply bails out with "error in line NN", with NN == the last line of the sysconfig/iptables line <NedSlider> hmm, that's not good <NedSlider> we'll get that note added to our known issues section I've added a note to the known issues section here: http://elrepo.org/tiki/kernel-ml [^] |
|
(0000434) wolfy (updater) 2010-12-08 08:56 |
For the record: I've recompiled iptables-1.4.7-3.el6.src.rpm against kernel-ml-*-2.6.26-1.elrepo and - at least for the options I am interested in - it seems to work OK. However, given that there are a few differences between the netfilter options compiled in RHEL6's kernel and kernel-2.6.36-1.elrepo, I am 99% sure that there do exist problems. However, there should be fewer problems compared to stock iptables-1.3.5. |
|
(0000435) wolfy (updater) 2010-12-08 09:12 edited on: 2010-12-10 18:17 |
I've attached the modified specs which allow the iptables package taken from RHEL 6 to be built for CentOS 5 kernel-ml-spec must be modified because: - iptables needs the kernel-headers appropriate for the 2.6.36-kernel - mock brings in glibc-devel, which in turn insists in bringing in kernel-headers (not kernel-ml-headers) - kernel-ml-headers has an explicit "Conflict" with kernel-headers - kernel-ml-headers and kernel-headers conflict also at file level, as they provide a lot of common include files |
|
(0000438) wolfy (updater) 2010-12-11 21:48 |
Being a noisy person as I am, I just wanted to let you know that iptables-1.4.9-2.fc15.src.rpm ( from fedora rawhide / 12.12.2010 ) can be rebuilt in mock unmodified and seems to work OK [ with my firewall at least ] in C5 + kernel-ml-2.6.36-1. Only requirement is to have kernel-ml-headers provide [ and not conflict with stock ] kernel-headers. Note that I did NOT do exhaustive tests, but only the few basic features that I need on the particular host where I was forced to ditch the stock Centos kernel. Here is an excerpt of the output of service iptables status (IPs sanitized, duplicate/not relevant rules deleted): [root@synps-ca ~]# /etc/init.d/iptables status Table: filter Chain INPUT (policy ACCEPT) num target prot opt source destination 1 ACCEPT all -- x.y.z 0.0.0.0/0 2 SSHSCAN tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:22 state NEW 3 ACCEPT tcp -- 192.168.50.17 0.0.0.0/0 multiport sports 1704,1705 Chain FORWARD (policy ACCEPT) num target prot opt source destination Chain OUTPUT (policy ACCEPT) num target prot opt source destination 1 ACCEPT all -- 0.0.0.0/0 x.y.z 2 ACCEPT tcp -- 0.0.0.0/0 192.168.50.17 multiport dports 1704,1705 Chain SSHSCAN (1 references) num target prot opt source destination 1 ACCEPT all -- a.b.c.d 0.0.0.0/0 2 all -- 0.0.0.0/0 0.0.0.0/0 recent: SET name: SSH side: source 3 DROP all -- 0.0.0.0/0 0.0.0.0/0 recent: UPDATE seconds: 900 hit_count: 5 name: SSH side: source |
|
(0000465) dag (administrator) 2010-12-21 15:04 |
The problem is that we cannot provide kernel-headers, since we conflict with it. And even if we could provide it, I don't think we can remove kernel-headers and install kernel-ml-headers in an atomic action, so people wouldn't be able to install it properly. The only way to fix it, is by removing kernel-headers by force, and installing kernel-ml-headers and ignore any problems from yum/rpm in the meantime. I don't think we can fix this properly :-( |
|
(0000466) burakkucat (administrator) 2010-12-22 11:01 |
"Only requirement is to have kernel-ml-headers provide [ and not conflict with stock ] kernel-headers." As you appreciate, we cannot build kernel-ml-headers that way (as much as I would like to do so) and so it is up to any person actually requiring the newer kernel headers package to do as you have done. With regards to your modifications in the spec file, it's all quite logical (and not laughable). |
| Mantis 1.1.8[^] Copyright © 2000 - 2009 Mantis Group |