On 08/06/2013 12:01 PM, Eric Blake wrote:
On 08/06/2013 09:24 AM, Stefan Berger wrote:
iptables version 1.4.16 and later automatically convert -m state --state ...
to -m conntrack --ctstate ... In the test cases we will then only see 'ctstate'
and convert that back to the older 'state' before comparing actual against
expected output.
Signed-off-by: Stefan Berger <stefanb@xxxxxxxxxxxxxxxxxx>
---
+probeIptablesCtstate() {
+ rev=$(iptables --version | \
+ sed -n 's/.*v\([[:digit:]].\)/\1/p' |
+ gawk -F. '{print $1 * 1000000 + $2 * 1000 + $3 }')
+ # 1.4.16 or later uses ctstate
+ if [ $rev -ge 1004016 ]; then
Version number probes are inherently fragile. Can you do a feature
probe instead, in case someone backports this feature to a build of
iptables that reports an earlier version?
Puzzled ... We had a similar case with the kernel version and the
--ctdir ORIGINAL versus REPLY where I had a feature probe first but then
ended up probing for the version of the kernel disregarding all these
backporting possibilities. So why would we do this in this case?
+ if [ $IPTABLES_USE_CTSTATE -ne 0 ]; then
+ #change ctstate tback o state
+ sed -i "s/ctstate/state/" ${tmpfile}
Do we even need the version/feature probe? What if we just ALWAYS do
this substitution? It won't hurt on older iptables (it will just be a
no-op).
You are probably right about that. Currently nwfilter does not create
rules with --ctstate and will only do so for newer versions of iptables.
Stefan
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list