From: Patrick McHardy <kaber@trash.net>
To: johnpeng <johnpeng@unitytek.com.tw>
Cc: netfilter-devel@lists.netfilter.org
Subject: Re: Multiple calls of check functions
Date: Mon, 02 Apr 2007 13:28:23 +0200 [thread overview]
Message-ID: <4610E8D7.3000701@trash.net> (raw)
In-Reply-To: <20070402110756.409EE9489E@stinky.trash.net>
johnpeng wrote:
> Dear all:
> When I issue the command with debug version of the SAME target (I am
> using kernel 2.6.17.7 and iptables 1.3.5)
> "iptables -t nat -A PREROUTING -d 10.10.10.1 -j SAME -to
> 172.31.0.1-172.31.0.3"
> I find that the check function of SAME target would be called multiple
> times, any following SNAT,DNAT rules would call the check function of the
> SAME
> Target , however, I didn't see the same situation in kernel 2.4 , is that
> due to some framework change in kernel 2.6 ?
No, that has always been the case. Every rule you add results in an
entire new ruleset from the kernels POV, so each rule is completely
validated again.
> And
> When we issue the removal "iptables -t nat -D PREROUTING -d 10.10.10.1 -j
> SAME -to 172.31.0.1-172.31.0.3",
> Iptables get reply of "iptables: No chain/target/match by that name",
> it seems the memory comparison is not equal with user level and kernel
> level passed target info data structure,
> Any solution?
Unfortunately no, the SAME target is unfixable broken in this regard:
struct ipt_same_info
{
unsigned char info;
u_int32_t rangesize;
u_int32_t ipnum;
u_int32_t *iparray;
/* hangs off end. */
struct ip_nat_range range[IPT_SAME_MAX_RANGE];
};
The pointer contains random content when dumping the rules from the
kernel, so we can't compare it. The usual way to deal with this is
to only compare the first n bytes, but that doesn't work in case
of SAME since we have data that must be compared following the
pointer.
The SAME target is obsolete and SNAT should also uses the same IPs
for the same source nowadays, so I'd suggest you simply use SNAT.
next parent reply other threads:[~2007-04-02 11:28 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20070402110756.409EE9489E@stinky.trash.net>
2007-04-02 11:28 ` Patrick McHardy [this message]
2007-04-02 12:37 ` Multiple calls of check functions johnpeng
[not found] <20070402123757.8117C948BF@stinky.trash.net>
2007-04-02 12:52 ` Patrick McHardy
2007-04-02 9:22 johnpeng
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=4610E8D7.3000701@trash.net \
--to=kaber@trash.net \
--cc=johnpeng@unitytek.com.tw \
--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.