All of lore.kernel.org
 help / color / mirror / Atom feed
* re: find_appropriate_src() BUG also exist in 2.4.24
@ 2004-04-04 22:37 Phil Oester
  2004-04-08  6:02 ` zhi wang
  0 siblings, 1 reply; 10+ messages in thread
From: Phil Oester @ 2004-04-04 22:37 UTC (permalink / raw)
  To: netfilter-devel

I too am having lockups every few hours on a heavily used gateway.  

Back in September, Rusty offered this patch:

http://lists.netfilter.org/pipermail/netfilter-devel/2003-September/012388.html

Which to this point is not in either 2.4 or 2.6, but looks as though
it may actually fix the endless loop we seem to be experiencing.

Alternatively, the following patch was merged in 2.6, but is not present
in 2.4.24 -- could this also help?

--- 1.34/net/ipv4/netfilter/ip_nat_core.c	Sun Apr  4 15:21:19 2004
+++ 1.35/net/ipv4/netfilter/ip_nat_core.c	Sun Apr  4 15:21:19 2004
@@ -421,7 +421,8 @@
 			*tuple = ((struct ip_conntrack_tuple)
 				  { *manip, orig_tuple->dst });
 			DEBUGP("get_unique_tuple: Found current src map\n");
-			return 1;
+			if (!ip_nat_used_tuple(tuple, conntrack))
+				return 1;
 		}
 	}


Any thoughts on either of the above would be appreciated.

Phil Oester

^ permalink raw reply	[flat|nested] 10+ messages in thread
* Re: find_appropriate_src() BUG also exist in 2.4.24
@ 2004-04-03  2:01 zhi wang
  2004-04-03  9:47 ` Martin Josefsson
  0 siblings, 1 reply; 10+ messages in thread
From: zhi wang @ 2004-04-03  2:01 UTC (permalink / raw)
  To: Netfilter Develop

>Still consider  a simple SNAT, without CONFIG_IP_NF_NAT_LOCAL selected 
>
>[ Client A ] -----> [ Box B ] ----> [ Server C ]
>iptalbes -A POSTROUTING -t nat -p udp  -j SNAT --to-source B:2000-3000

>when two udp connection built:
>ct1: ORIG A.1---> C.1   REPLY  C.1 ---> B.2000
>ct2: ORIG B.2000 ---> C.2 REPLY C.2 ---> B.2000

>then the third will hang on the system

>B.2000 ---> C.1

After some email communication with wanght@legend, and cleared my own
misunderstander, I agree that this is a bug. The following steps can faithfully
hang the linux 2.4.24 machine.
     [1.1.1.2]<--->[1.1.1.1  2.2.2.1] <--->[2.2.2.2]
     iptalbes -A POSTROUTING -t nat -j SNAT --to-source 2.2.2.1:2000-3000

1. Deselect the CONFIG_IP_NF_NAT_LOCAL.
   set up the route:
   at [1.1.1.2]: ip route add 2.2.2.0/24 via 1.1.1.1
   at [2.2.2.2]: ip route add 1.1.1.0/24 via 2.2.2.1
   at [1.1.1.1]: echo 1 > /proc/sys/net/ipv4/ip_forward

2. at [2.2.2.2] execute:
   nc -l -p 1023
   nc -l -p 1024

3. at [1.1.1.2] execute:
   nc -n -p 1023 2.2.2.2 1023
   at [1.1.1.1], assume port 2000 is used. that is, there is a conntrack:
             {1.1.1.2:1023-->2.2.2.2:1023, 2.2.2.2:1023-->2.2.2.1:2000}

4. at [1.1.1.1] execute:
   nc -n -s 2.2.2.1 -p 2000 2.2.2.2 1024
   then another conntrack will be created:
             {2.2.2.1:2000-->2.2.2.2:1024,  2.2.2.2:1024-->2.2.2.1:2000}

5. at [1.1.1.1] again execute:
   nc -n -s 2.2.2.1 -p 2000 2.2.2.2 1023
   Then NF will try to create a conntrack with:
             {2.2.2.1:2000-->2.2.2.2:1023, 2.2.2.2:1023-->2.2.2.1:2000}
   This will trigger the dead loop.


Why CONFIG_IP_NF_NAT_LOCAL disabled:
   When CONFIG_IP_NF_NAT_LOCAL is enabled, a null binding will be allocated at
LOCAL_OUT hook. While a LOCAL_OUT hook is consided for DNAT, nat will not call
find_appropriate_src, and it will try to do implicit source NAT. So, the
conntrack will be change to something like {2.2.2.1:2000-->2.2.2.2:1023,
2.2.2.2:1023-->2.2.2.1:2001} before the POSTROUTING hook is called, dead loop
will NOT occur. I believe this DNAT identity is the power of
CONFIG_IP_NF_NAT_LOCAL. It covers this and the LIST_DELETE bug. Because it is
consided as DNAT, the PREROUTING hook will NOT call ip_nat_rule_find in
LIST_DELETE bug setup. 

Current 2.6 kernel has fixed this bug. It should be used in current 2.4 kernel
also.

Some thoughts:
The purpose of find_appropriate_src as stated by the comment in the source
code, "If this srcip/proto/src-proto-part is currently mapped,and that same
mapping gives a unique tuple within the given range, use that". I am just
wondering why we can't be the first to use that mapping, if it is valid within
the given range?


=====
--
Regards
Wang, zhi

__________________________________
Do you Yahoo!?
Yahoo! Small Business $15K Web Design Giveaway 
http://promotions.yahoo.com/design_giveaway/

^ permalink raw reply	[flat|nested] 10+ messages in thread
* find_appropriate_src() BUG  also exist in 2.4.24
@ 2004-03-04  8:32 wanghtb
  2004-03-04  9:40 ` KOVACS Krisztian
  0 siblings, 1 reply; 10+ messages in thread
From: wanghtb @ 2004-03-04  8:32 UTC (permalink / raw)
  To: netfilter-devel; +Cc: hidden

Hi, all

Still consider  a simple SNAT, without CONFIG_IP_NF_NAT_LOCAL selected 

[ Client A ] -----> [ Box B ] ----> [ Server C ]
iptalbes -A POSTROUTING -t nat -p udp  -j SNAT --to-source B:2000-3000

when two udp connection built:
ct1: ORIG A.1---> C.1   REPLY  C.1 ---> B.2000
ct2: ORIG B.2000 ---> C.2 REPLY C.2 ---> B.2000

then the third will hang on the system

B.2000 ---> C.1


So, I think ip_nat_local_fn() should be called in any situation:-)

^ permalink raw reply	[flat|nested] 10+ messages in thread
end of thread, other threads:[~2004-04-08  6:02 UTC | newest]

Thread overview: 10+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2004-04-04 22:37 find_appropriate_src() BUG also exist in 2.4.24 Phil Oester
2004-04-08  6:02 ` zhi wang
  -- strict thread matches above, loose matches on Subject: below --
2004-04-03  2:01 zhi wang
2004-04-03  9:47 ` Martin Josefsson
2004-04-04 16:44   ` KOVACS Krisztian
2004-04-04 16:50     ` Martin Josefsson
2004-04-05 12:20       ` zhi wang
2004-04-05 12:44         ` KOVACS Krisztian
2004-03-04  8:32 wanghtb
2004-03-04  9:40 ` KOVACS Krisztian

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.