On 08.12, Pablo Neira Ayuso wrote:
> Rules with header fields that rely on the generic integer datatype
> from sets are not matching, eg.
>
> nft add rule filter input udp length { 9 } counter
>
> This set member is an integer represented in host byte order, which
> obviously doesn't match the header field (in network byte order).
>
> Since the integer datatype has no specific byteorder, we could rely
> on the expression byteorder instead when configuring the context,
> before we evaluate the list of set members.
>
> This approach doesn't solve the problem in the delinearize path, since
> we infer the datatype from the set keytype, ie. integer_type. But this
> type has no specific byteorder (BYTEORDER_INVALID) so
> netlink_delinearize_setelem() doesn't know if we sent the integer in
> host or network byteorder.
>
> To resolve this, this patch adds TYPE_BE_INTEGER, a dummy integer
> subtype, and use it from the protocol header definitions. Thus, the
> set keytype indicates what byteorder had been used for the set members.
I don't like encoding the byteorder in the datatype. Is there anything
wrong with setting the byteorder in delinearization after we know the
related expression?
In your example it can easily be deduced from the datatype.
--
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
