Some anonymous sets aren't displayed correctly, look at the result of
following commands.
nft> add rule ip filter input meta length {1000, 2000} counter
nft> add rule ip filter input meta iifname {eth0, eth1} counter
nft> list table ip filter
table ip filter {
chain input {
type filter hook input priority 0;
meta length { 3892510720, 3490119680} counter packets 0 bytes 0
iifname { "", ""} counter packets 0 bytes 0
}
}
This is because the data types used in meta length and meta iifname are
integer and string, whose byteorders are BYTEORDER_INVALID.
In netlink_delinearize_setelem, the value stored in expr cannot be converted
to host byte order, so the value cannot be displayed correctly. In order to fix
this bug, just set the byteorder of integer_type and string_type to
BYTEORDER_HOST_ENDIAN.
But I have some questions. As anonymous sets can be used with meta ifname,
should we add a new datatype as follows, so normal sets can be created and then
used by meta ifname?
static const struct datatype ifname_type = {
.type = TYPE_IFNAME,
.name = "ifname",
.desc = "interface name",
.byteorder = BYTEORDER_HOST_ENDIAN,
.size = IFNAMSIZ * BITS_PER_BYTE,
.basetype = &string_type,
};
Besides meta ifname, many other selectors appear to be suffering from the same
problem, such as: meta length, tcp window, {icmp, udp, tcp, ip, ...} checksum,
{ah, icmp, tcp, ...} sequence. Should we add new datatypes for them? Who
is interested in packets with exact checksum or sequence? I wonder.
So, is it a better way to forbid such anonymous sets completely? We can do some
work in implicit_set_declaration. If set->keylen != set->keytype->size, return
with a error message.
Pablo, what's your opinion?
--
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
