From: Patrick McHardy <kaber@trash.net>
To: Pablo Neira Ayuso <pablo@netfilter.org>
Cc: Harald Welte <laforge@netfilter.org>,
Netfilter Development Mailinglist
<netfilter-devel@lists.netfilter.org>,
Yasuyuki Kozakai <yasuyuki.kozakai@toshiba.co.jp>
Subject: Re: [PATCH 1/4] Fix expectaction mask dumping, take #3
Date: Thu, 16 Feb 2006 10:36:20 +0100 [thread overview]
Message-ID: <43F44794.1080203@trash.net> (raw)
In-Reply-To: <43EFF176.3070505@netfilter.org>
Pablo Neira Ayuso wrote:
> [CTNETLINK] Fix expectaction mask dumping
>
> The expectation mask has some particularities that make handle in a
> different way. The protocol number fields can be set to non-valid
> protocols, ie. l3num is set to 0xFFFF. Since that protocol does not
> exist, the mask tuple will not be dumped. Moreover, this results in a
> kernel panic when nf_conntrack accesses the array of protocol handlers,
> that is PF_MAX (0x1F) long.
>
> This patch introduces the function ctnetlink_exp_dump_mask, that
> correctly dumps the expectation mask. Such function uses the l3num value
> from the expectation tuple that is a valid layer 3 protocol number.
This part looks fine to me, apart from one minor nitpick :)
> Besides, this modification introduces the attribute CTA_IP_L3NUM.
> Although the layer 3 protocol information is sent in the nfnetlink
> header, if the message contains information about an expectation, it
> will contain information about the master conntrack (just one of the
> tuples), the expectation tuple and the expectation mask. In this case,
> the value of l3num in the expectation mask is not the same that is set
> in the nfnetlink message. That is why we need another field that contain
> the value of l3num.
I'm not sure I understand. The new attribute still contains the same
value as the netlink header, doesn't it? So userspace should currently
have at least two possibilities to get the correct value:
- use the value from the netlink header
- use the value from the tuple that comes with the mask, as the first
part of your patch does. This seems most logically to me since the
mask and the tuple belong together.
> @@ -77,33 +75,47 @@ nfattr_failure:
> }
>
> static inline int
> -ctnetlink_dump_tuples(struct sk_buff *skb,
> - const struct nf_conntrack_tuple *tuple)
> +ctnetlink_dump_tuples_ip(struct sk_buff *skb,
> + const struct nf_conntrack_tuple *tuple,
> + struct nf_conntrack_l3proto *l3proto)
> {
> - struct nfattr *nest_parms;
> - struct nf_conntrack_l3proto *l3proto;
> int ret = 0;
> -
> - l3proto = nf_ct_l3proto_find_get(tuple->src.l3num);
> -
> - nest_parms = NFA_NEST(skb, CTA_TUPLE_IP);
> + struct nfattr *nest_parms = NFA_NEST(skb, CTA_TUPLE_IP);
> + u_int8_t l3num = (u_int8_t)tuple->src.l3num;
The cast is unnecessary.
next prev parent reply other threads:[~2006-02-16 9:36 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-02-13 2:39 [PATCH 1/4] Fix expectaction mask dumping, take #3 Pablo Neira Ayuso
2006-02-13 11:13 ` Harald Welte
2006-02-16 9:36 ` Patrick McHardy [this message]
2006-02-16 10:05 ` Harald Welte
2006-02-16 20:11 ` Patrick McHardy
2006-02-21 12:16 ` Yasuyuki KOZAKAI
[not found] ` <200602211216.k1LCG18I024522@toshiba.co.jp>
2006-02-23 9:43 ` Patrick McHardy
2006-02-23 10:10 ` Yasuyuki KOZAKAI
2006-02-21 13:03 ` Pablo Neira Ayuso
2006-02-22 3:20 ` Pablo Neira Ayuso
2006-02-22 13:01 ` Yasuyuki KOZAKAI
[not found] ` <200602221301.k1MD1lIb015798@toshiba.co.jp>
2006-02-23 9:48 ` Patrick McHardy
2006-02-23 11:10 ` Yasuyuki KOZAKAI
[not found] ` <200602231110.k1NBA71v013563@toshiba.co.jp>
2006-02-23 11:13 ` Patrick McHardy
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=43F44794.1080203@trash.net \
--to=kaber@trash.net \
--cc=laforge@netfilter.org \
--cc=netfilter-devel@lists.netfilter.org \
--cc=pablo@netfilter.org \
--cc=yasuyuki.kozakai@toshiba.co.jp \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.