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

[Jesse Peng <jesse@deansoft.com.tw>]

[-- 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 --]