From: Jesse Peng <jesse@deansoft.com.tw>
To: netfilter <netfilter-devel@lists.netfilter.org>
Subject: again!!! the 3rd time, why we need find_appopriate_src? rether than just check in_range?
Date: Thu, 04 Dec 2003 12:42:36 +0800 [thread overview]
Message-ID: <3FCEBB3C.1000309@deansoft.com.tw> (raw)
According to the concerning comments and code within get_unique_tupple
in ip_nat_core.c, I cite them as below:
/* 1) If this srcip/proto/src-proto-part is currently mapped,
and that same mapping gives a unique tuple within the given
range, use that.
This is only required for source (ie. NAT/masq) mappings.
So far, we don't do local source mappings, so multiple
manips not an issue. */
if (hooknum == NF_IP_POST_ROUTING) {
struct ip_conntrack_manip *manip;
manip = find_appropriate_src(orig_tuple, mr);
if (manip) {
/* Apply same source manipulation. */
*tuple = ((struct ip_conntrack_tuple)
{ *manip, orig_tuple->dst });
DEBUGP("get_unique_tuple: Found current src map\n");
if (!ip_nat_used_tuple(tuple, conntrack))
return 1;
}
According to above, this circumstance only limited at POST_ROUTING hook,
then the question is as follow:
1.Since ip_nat_fn is called both during PREROUTING and POSTROUTING hook,
then we've sure while a new packet passing PREROUTING, the ip_nat_fn
have called ip_nat_rule_find, then the ip_nat_rule_find graranting that
even no rule found the output tuple will be unique(through the
compensation by allocate_null_biding).
2.While during POSTROUTE, the input tuple: orig_tuple to
get_unique_tuple is right one the output tuple above mentioned, so it is
still unique!!
3.Then why can't we just check if the src of the orig_tuple "in range"
the mr. If it is, then all we need to do is to set the
*tuple=*orig_tuple, and return 1.
So can the new code look like below?
if (hooknum == NF_IP_POST_ROUTING) {
if ( in_range(orig_tuple, &orig_tuple->src, mr)) {
/* Apply same source manipulation. */
*tuple = *orig_tuple;
DEBUGP("get_unique_tuple: Found current src map\n");
/*Since we've sure the orig_tuple is unique*/
/*if (!ip_nat_used_tuple(tuple, conntrack))*/
return 1;
}
Ok!!!!May be this doubt is very fool wrong, and nor the question ever
exist, Please give me some correct hint.Because this remaining
disunderstanding fool me so long and almost destroy my life!!
Thanx!! a lot.
Your Sincerely
next reply other threads:[~2003-12-04 4:42 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-12-04 4:42 Jesse Peng [this message]
2003-12-04 11:59 ` again!!! the 3rd time, why we need find_appopriate_src? rether than just check in_range? Harald Welte
2003-12-08 8:37 ` Jesse Peng
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=3FCEBB3C.1000309@deansoft.com.tw \
--to=jesse@deansoft.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.