Hide Forgot
We now have customer bugs requesting features that have been introduced upstream quite recently, and it would be impractical and risky to introduce them with the big gap we currently have in our codebase. We had recent, critical bugs, that were fixed upstream, but we couldn't conveniently backport any patch, and we had to resort to RHEL-only patches. See e.g. bz1517397. Furthermore, the userspace component is more recent than the kernel implementation, and supports set types that are not supported in kernel, causing obvious inconsistencies. Also the current upstream test suite is unusable with our current kernel implementation. This poses a strong case for a rebase of the kernel component.
Patch(es) committed on kernel repository and an interim kernel build is undergoing testing
Patch(es) available on kernel-3.10.0-894.el7
I have run upstream test: git clone git://git.netfilter.org/ipset on kernel-3.10.0-898.el7 and get result: https://beaker.engineering.redhat.com/recipes/5307771#task74304094 all items gone through review result.log，there is only one item failed: Failed test: ./check_klog.sh 10.255.255.64 udp 1025 netiface that because when exec sendip -p ipv4 -id 10.255.255.254 -is 10.255.255.64 -p udp -ud 80 -us 1025 10.255.255.254 there is a few iptables rule remain: Chain OUTPUT (policy ACCEPT 29 packets, 3576 bytes) pkts bytes target prot opt in out source destination 0 0 LOG all -- * * 0.0.0.0/0 0.0.0.0/0 match-set test dst,dst LOG flags 0 level 4 prefix "in set netiface: " 1 28 DROP all -- * * 0.0.0.0/0 10.255.255.254 That drop cause sendto() EPERM (Operation not permitted). sendip use RAW socket to generate IP payload. I don't think it's a issue.
I also cover these type: - hash:net,net - hash:net,port,net - hash:ip,mark - hash:ip,mac basic function works fine. no issue found.
There is a issue hash:mac can't be matched as a destination MAC address. Bug 1607252
Hi Yi Chen, (In reply to yiche from comment #12) > There is a issue hash:mac can't be matched as a destination MAC address. > Bug 1607252 Wouldn't it make sense to keep this as VERIFIED, though, and track the additional issue separately?
Ok，We can track it separately.
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://access.redhat.com/errata/RHSA-2018:3083