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, 2003-11-04 11:32:55-08:00, 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