From: Peter Riley <Peter.Riley@hotpop.com>
To: Patrick McHardy <kaber@trash.net>
Cc: netfilter-devel@lists.netfilter.org
Subject: Re: [PATCH] Last vestiges of NFC
Date: Thu, 30 Aug 2007 08:13:51 -0700 [thread overview]
Message-ID: <46D6DEAF.9010009@hotpop.com> (raw)
In-Reply-To: <46D5A5B9.2030107@trash.net>
Patrick McHardy wrote:
>
> I count 132 occurences of nfcache (a few are in headers that must stay
> though). I'll happily apply a patch that kills them all.
>
Patrick, yes I get 134 occurrences on 132 lines in current svn.
The breakdown appears to me to be:
51 init() function declarations in match and target extensions
52 parse() function declarations in match extensions only
(not counting connlimit and multiport which are more complicated than
one declaration per file)
2 parse related function declarations in connlimit
4 parse related function declarations in multiport
5+5 calls in iptables.c & ip6tables.c to ->init() or ->parse() members above
3 occurrences in xtables.h that prototype the above:
struct xtables_match
{...
void (*init)(struct xt_entry_match *m, unsigned int *nfcache);
int (*parse)(int c, char **argv, int invert, unsigned int *flags,
const void *entry, unsigned int *nfcache, struct xt_entry_match **match);
struct xtables_target
{...
void (*init)(struct xt_entry_target *t, unsigned int *nfcache);
3+3 occurrences in dump_entry() in libip4tc.c and libip4tc.c for debugging:
printf("Cache: %08X ", e->nfcache);
if (e->nfcache & NFC_ALTERED) printf("ALTERED ");
if (e->nfcache & NFC_UNKNOWN) printf("UNKNOWN ");
It seems that there is good reason for printing out nfcache contents as long as
those bits are still present in structs ipt_entry/ip6t_entry defined in headers
on the kernel side. After all, this is how I tracked down the problem I am
reporting to begin with!
What all this leaves remaining are the occurrences I mentioned in previous message
whose removal doesn't break anything:
1+1 in libipt_policy.c and libip6t_policy.c init() functions where NFC bits are
still being set:
*nfcache |= NFC_UNKNOWN;
These (among similar others that have already been removed) crept in
subsequent to Pablo Neira's NFC-killer patches that I mentioned in original
post.
2+2 occurrences in the libip4tc.c and libip4tc.c is_same() comparisons:
if (a->nfcache != b->nfcache
...) return NULL;
These are the occurrences causing problems. As mentioned, this prevents
iptables from being able to delete-by-match any rules created by old
userspace tools that still set nfcache bits in entries -- the entries are
not considered "same" because (only) the nfcache bits differ (modulo the
match mask of course).
-----
=134 Total
Please let me know if I can do anything more regarding this.
Best Regards,
Peter
next prev parent reply other threads:[~2007-08-30 15:13 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-08-25 17:21 [PATCH] Last vestiges of NFC Peter Riley
2007-08-25 18:07 ` Peter Riley
2007-08-29 16:58 ` Patrick McHardy
2007-08-30 15:13 ` Peter Riley [this message]
2007-08-30 18:40 ` Jan Engelhardt
2007-08-31 14:25 ` Peter Riley
2007-08-31 16:19 ` Patrick McHardy
2007-09-01 19:31 ` Peter Riley
2007-09-01 19:57 ` Peter Riley
2007-09-02 12:01 ` Patrick McHardy
2007-09-02 11:59 ` Patrick McHardy
2007-08-31 9:38 ` 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=46D6DEAF.9010009@hotpop.com \
--to=peter.riley@hotpop.com \
--cc=kaber@trash.net \
--cc=netfilter-devel@lists.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 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.