All of lore.kernel.org
 help / color / mirror / Atom feed
From: Philip Craig <philipc@snapgear.com>
To: paulm@routefree.com
Cc: netfilter-devel@lists.netfilter.org, paulm@broadon.com
Subject: Re: PPTP connection tracking fixes
Date: Tue, 21 Jan 2003 18:25:03 +1000	[thread overview]
Message-ID: <3E2D03DF.4090407@snapgear.com> (raw)
In-Reply-To: 200301180029.h0I0T3d29430@stilton.routefree.com

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

paulm@routefree.com wrote:
> My solution was just to turn the
> 
> #ifdef CONFIG_IP_NF_NAT_LOCAL
> 
> into
> 
> #if 0
> 
> thus removing this section of code.  Things seem to work fine after
> this change, but perhaps there are other cases that I don't understand
> in which this change would break things.  Harald, do you see any harm
> in this solution?

If you do this and turn on CONFIG_NETFILTER_DEBUG, you get:

IP_NF_ASSERT: ipt_do_table:ip_tables.c:290

which is a result of ipt_do_table being called for the LOCAL_IN
hook in the nat table.

I've attached a patch that moves the #ifdef down a bit, so that
bindings can still be set up for expectations, but otherwise
we skip doing ip_nat_rule_find() for the LOCAL_IN hook.

-- 
Philip Craig     Software Engineer     http://www.SnapGear.com
philipc@snapgear.com  Ph: +61 7 3435 2821  Fx: +61 7 3891 3630
SnapGear  -  Custom Embedded Solutions and Security Appliances

[-- Attachment #2: nat_local.patch --]
[-- Type: text/plain, Size: 978 bytes --]

diff -u -r1.3 ip_nat_standalone.c
--- linux-2.4.x/net/ipv4/netfilter/ip_nat_standalone.c	9 Dec 2002 15:18:06 -0000	1.3
+++ linux-2.4.x/net/ipv4/netfilter/ip_nat_standalone.c	21 Jan 2003 08:20:45 -0000
@@ -109,12 +109,6 @@
 		}
 		/* Fall thru... (Only ICMPs can be IP_CT_IS_REPLY) */
 	case IP_CT_NEW:
-#ifdef CONFIG_IP_NF_NAT_LOCAL
-		/* LOCAL_IN hook doesn't have a chain and thus doesn't care
-		 * about new packets -HW */
-		if (hooknum == NF_IP_LOCAL_IN)
-			return NF_ACCEPT;
-#endif
 		info = &ct->nat.info;
 
 		WRITE_LOCK(&ip_nat_lock);
@@ -130,6 +124,14 @@
 				ret = call_expect(master_ct(ct), pskb, 
 						  hooknum, ct, info);
 			} else {
+#ifdef CONFIG_IP_NF_NAT_LOCAL
+				/* LOCAL_IN hook doesn't have a chain and thus
+				 * doesn't care about new packets -HW */
+				if (hooknum == NF_IP_LOCAL_IN) {
+					WRITE_UNLOCK(&ip_nat_lock);
+					return NF_ACCEPT;
+				}
+#endif
 				ret = ip_nat_rule_find(pskb, hooknum, in, out,
 						       ct, info);
 			}

  parent reply	other threads:[~2003-01-21  8:25 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-01-18  0:29 PPTP connection tracking fixes paulm
2003-01-21  1:50 ` Philip Craig
2003-01-21  8:25 ` Philip Craig [this message]
2003-01-30  0:31 ` another PPTP conntrack problem (no fix this time) Paul Mielke
2003-01-30  7:34   ` Philip Craig
2003-01-31 12:04     ` Harald Welte
2003-01-31 20:50     ` Paul Mielke
2003-02-05  8:23       ` Philip Craig
2003-02-18  1:21         ` [PATCH] " Philip Craig

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=3E2D03DF.4090407@snapgear.com \
    --to=philipc@snapgear.com \
    --cc=netfilter-devel@lists.netfilter.org \
    --cc=paulm@broadon.com \
    --cc=paulm@routefree.com \
    /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.