> You can't expect to issue two different iptables statements (as in
your example above) and get the same number of matches! Not going to
happen, is it? By the same token, if I execute the following two
statements:
I would certainly expect the two above statements to be identical.
They are not! How many times would you like me to repeat that: 'in' =
use and match on incoming interfaces *only*, 'out' = use and match on
outgoing interfaces *only*. It is appropriately named as well. I
considered 'in' to be 'incoming_network_interface' at one point, but
opted for the short version instead. ;-)
As an uninterested third party only slightly following along this
discussion. I would expect this to be a purely userspace change. Ie.
just change src->in and dst->out on display, and make src==in and
dst==out on input. I see no reason for any kernel space changes or
kernel version bumps.
And why is that exactly? What is stopping me, or everybody else for that
matter, to make "kernel version bumps", as you put it? Changes to
various netfilter components often require kernel submissions as well as
userspace changes, simply because of the scope of those changes. Nothing
is precluding me, or anybody else, from applying these changes.
> The above will also produce "different results for the same member
sets with the same elements against the same packets". So why is this
not "unacceptable" then?
Because src != dst ?
Exactly my point! src != dst, but src != in as well (see above). 'src' =
'in' (and use the the term "equal" loosely here) *only* in the scope of
the 'iface' part of hash:net,iface set describing network interface matches.
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
