Fabian Hugelshofer wrote:
Patrick McHardy wrote:
Patrick McHardy wrote:
Fabian Hugelshofer wrote:
Is the zeroing of the inverted tuple in nf_ct_invert_tuple really
required? As far as I can see all fields are set by the subsequent
code.
It dependfs on the protocol family. For IPv6 its completely
unnecessary, for IPv4 the last 12 bytes of each address need
to be zeroes. We could push this down to the protocols to
behave more optimally (actually something I started and didn't
finish some time ago).
Actually that really is necessary because we have padding in the
tuple on at least ARM.
As you write the remaining 12 bytes for IPv4 can easily be handled in
the l3protocol. The original tuple is already initialised properly and
one would just have to replace things like
tuple->src.u3.ip = orig->dst.u3.ip;
with
tuple->src.u3.all = orig->dst.u3.all;
in nf_conntrack_l3proto_ipv4.c.
Correct.
Why do you think the padding causes problems? For hashing e.g. src/dst
.u3 and .u are referenced independently of potential padding. Where does
access to the padding data occur?
The hash function hashes the entire tuple in one go.
The padding needs to have deterministic content for
that.
--
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
