On Tue, Dec 09, 2014 at 07:53:21AM +0000, Patrick McHardy wrote:
> On 08.12, Pablo Neira Ayuso wrote:
> > nft list table filter
> > ...
> > cpu { 50331648, 33554432, 0, 16777216} counter packets 8 bytes 344
>
> I'm certain this used to work for mark values, so I'm wondering
> what broke it. We might have a more fundamental bug somewhere.
mark values don't use the integer_type, they use mark_type which has
an specific byteorder. So they work fine.
The problem is integer_type, it has no specific byteorder. Actually,
it is left unset so it is BYTEORDER_INVALID, which is handled when
importing/exporting as BYTEORDER_BIG_ENDIAN.
Solutions that I can see are:
1) Add specific integer_types, ie. be_integer_type (subtype of
integer) that uses BYTEORDER_BIG_ENDIAN so the datatype tells us
the endianness, but this doesn't seem convenient:
http://marc.info/?l=netfilter-devel&m=141806352422510&w=2
2) From the postprocess step as you suggested. In this case, if we see
an integer_type, we use the left-hand side expr->byteorder. Note that
integer_type is also used in several header fields (where this
should be a big endian integer). That case currently works because
BYTEORDER_INVALID defaults on BYTEORDER_BIG_ENDIAN when
importing/exporting. This new integer_postprocess() function should
be also called. This is what this patch does.
Let me know, thanks.
--
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
