From: Yanchuan Nian <ycnian@gmail.com>
To: pablo@netfilter.org
Cc: netfilter-devel@vger.kernel.org, Yanchuan Nian <ycnian@gmail.com>
Subject: Bug: Some anonymous sets aren't displayed correctly
Date: Mon, 11 Aug 2014 15:51:12 +0800 [thread overview]
Message-ID: <1407743472-9165-1-git-send-email-ycnian@gmail.com> (raw)
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?
reply other threads:[~2014-08-11 7:48 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1407743472-9165-1-git-send-email-ycnian@gmail.com \
--to=ycnian@gmail.com \
--cc=netfilter-devel@vger.kernel.org \
--cc=pablo@netfilter.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).