On Mon, Dec 08, 2014 at 06:31:55PM +0000, Patrick McHardy wrote:
> 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.
My initial patches went in that direction. However, then I noticed we
may have named sets that are not attached to rules yet, and those can
be listed via `nft list sets'.
--
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
