*ipset* rebased to Linux kernel version 4.17
The *ipset* kernel component has been upgraded to upstream Linux kernel version 4.17 which provides a number of enhancements and bug fixes over the previous version. Notable changes include:
* The following *ipset* types are now supported:
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:
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:
basic function works fine.
no issue found.
There is a issue hash:mac can't be matched as a destination MAC address.
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.