again!!! the 3rd time, why we need find_appopriate_src? rether than just check in_range?

again!!! the 3rd time, why we need find_appopriate_src? rether than just check in_range?

[Jesse Peng]

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

Re: again!!! the 3rd time, why we need find_appopriate_src? rether than just check in_range?

[Harald Welte]

[-- Attachment #1: Type: text/plain, Size: 1786 bytes --]

On Thu, Dec 04, 2003 at 12:42:14PM +0800, Jesse Peng wrote:
> 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 what about the cases where we have packets originated by the local
machine?  They will appear via ip_nat_local_fn() -> ip_nat_fn() ->
ip_nat_rule_find() attached to LOCAL_OUT only if CONFIG_IP_NF_NAT_LOCAL
is defined.

If not, the packet is actually only seen at POST_ROUTING, and we still
have to make sure the tuple is unique.
> Because this remaining disunderstanding fool me so long and almost
> destroy my life!!

it almost destroys yor life?  Is your employer going to fire you if you
don't understand netfilter code, or what ;) ?

> Your Sincerely

-- 
- Harald Welte <laforge@netfilter.org>             http://www.netfilter.org/
============================================================================
  "Fragmentation is like classful addressing -- an interesting early
   architectural error that shows how much experimentation was going
   on while IP was being designed."                    -- Paul Vixie

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: again!!! the 3rd time, why we need find_appopriate_src? rether than just check in_range?

[Jesse Peng]

[-- Attachment #1: Type: text/plain, Size: 4132 bytes --]

  First, very thanx for the reply, it just looks like a dry land finally 
meet some sweet rain drops. But execuse me for the still bother, it 
still remains some unclearing parts.

Harald Welte wrote:

>On Thu, Dec 04, 2003 at 12:42:14PM +0800, Jesse Peng wrote:
>  
>
>>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 what about the cases where we have packets originated by the local
>machine?  They will appear via ip_nat_local_fn() -> ip_nat_fn() ->
>ip_nat_rule_find() attached to LOCAL_OUT only if CONFIG_IP_NF_NAT_LOCAL
>is defined.
>
>If not, the packet is actually only seen at POST_ROUTING, and we still
>have to make sure the tuple is unique.
>
1.If the above is true, so the purpose of hash_by_src is only designed 
for local generated packets on the condition with the
CONFIG_IP_NF_NAT_LOCAL not set? and even that, it will mean so far while 
POSTROUTING the nat info not initialized yet, then how can it be 
currently mapped in the hash_by_src hash? as according to the comment:

/* 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.

2.I really want to realize  why  hash_by_src, because it's very hard to 
understand the way it prove the uniquity.

3.As you can notice, the partial source I pasted included a  line 
offered by Rusty for fix at NOV. 4, for the convenient, I paste here 
again as below:

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)) 
<------------------------------here it is
               return 1;  
       }

and the comment offered by Rusty as below:

ChangeSet@1.497.3182.19 <mailto:ChangeSet@1.497.3182.19>, 2003-11-04 11:32:55-08:00, rusty@rustcorp.com.au <mailto:rusty@rustcorp.com.au>
  [NETFILTER]: get_unique_tuple doesn't always return unique tuple.
  
  get_unique_tuple doesn't check that the tuple is unique if it finds
  a hash_by_src match.

Now I think maybe Rusty's concern is about smp racing,but since even 
hash_by_src also need to face the race, then after some cost effecience 
consider, should'nt the now code look like below?

if (hooknum == NF_IP_POST_ROUTING) {

           /*replace the more cost find_appropriate_src* with simple 
in_range*/
           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");
           /*We still have this below protection*/
           if (!ip_nat_used_tuple(tuple, conntrack))
               return 1;
       }
 

>  
>
>>Because this remaining disunderstanding fool me so long and almost
>>destroy my life!!
>>    
>>
>
>it almost destroys yor life?  Is your employer going to fire you if you
>don't understand netfilter code, or what ;) ?
>  
>
hm..Not exactly that!, Just because some projects potentially risk some 
on those complicated. So it's essential to have a good learning on it 
unless I really dare someday being kicked off from my office ;) !

>  
>
>>Your Sincerely
>>    
>>
>
>  
>



[-- Attachment #2: Type: text/html, Size: 6206 bytes --]