ipt_REDIRECT multirange + byte order fix

[bof@oknodo.bof.de]

--ELM956090657-7038-0_
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Hi all,

here's a small patch to ipt_REDIRECT.c (from 2.3.99-pre5), which did not
work for me out of the box. I'm using it to redirect on OUTPUT back to
a local port (where an ssh listens, nf_getsockname()s, and happily
connects again to some webservers behind an ssh tunnel).

I'm pretty sure that the byte order fixes are in the wrong place here,
but haven't looked further where to place them.

Apart from that glitch, I'd like to express eternal gratitute towards
all who made netfilter possible. This framework is a dream come true.

Patrick

--ELM956090657-7038-0_
Content-Type: text/plain; charset=ISO-8859-1
Content-Disposition: attachment; filename=nfdiff
Content-Description: nfdiff
Content-Transfer-Encoding: 7bit

--- linux-2.3.99-pre5/net/ipv4/netfilter/ipt_REDIRECT.c	Sat Apr 15 10:39:05 2000
+++ linux/net/ipv4/netfilter/ipt_REDIRECT.c	Sat Apr 15 13:23:32 2000
@@ -18,7 +18,8 @@
 #define DEBUGP(format, args...)
 #endif
 
-/* FIXME: Take multiple ranges --RR */
+/* FIXME: take more than one range??? */
+
 static int
 redirect_check(const char *tablename,
 	       const struct ipt_entry *e,
@@ -59,7 +60,7 @@
 	struct ip_conntrack *ct;
 	enum ip_conntrack_info ctinfo;
 	u_int32_t newdst;
-	const struct ip_nat_range *r = targinfo;
+	const struct ip_nat_multi_range *mr = targinfo;
 	struct ip_nat_multi_range newrange;
 
 	IP_NF_ASSERT(hooknum == NF_IP_PRE_ROUTING
@@ -76,12 +77,33 @@
 		newdst = (((struct in_device *)(*pskb)->dev->ip_ptr)
 			  ->ifa_list->ifa_local);
 
-	DEBUGP("redirect_target to 0x%08x\n", ntohs(newdst));
+	DEBUGP("redirect_target to 0x%08x, min=%d, max=%d, oldflags=%x\n",
+		ntohl(newdst),
+		(int) mr->range[0].min.tcp.port,
+		(int) mr->range[0].max.tcp.port,
+		mr->range[0].flags);
 	/* Transfer from original range. */
 	newrange = ((struct ip_nat_multi_range)
-		{ 1, { { r->flags | IP_NAT_RANGE_MAP_IPS,
+		{ 1, { { mr->range[0].flags | IP_NAT_RANGE_MAP_IPS,
 			 newdst, newdst,
-			 r->min, r->max } } });
+			 mr->range[0].min, mr->range[0].max } } });
+	/*
+	 * There seems to be a byte order SNAFU on the ports:
+	 *
+	 * The incoming ports here are in host byte order, but the tuple
+	 * that is created later seems to use the other byte order.
+	 * Reverse here to see whether things work... YUP, works now.
+	 *
+	 * Need to investigate the real culprit. Two debug messages below
+	 * they give me a "MAP_IPS PROTO_SPECIFIED..." message with the
+	 * wrong byte order (1293 instead of the 3333 I use for testing),
+	 * and two messages further "New: tuple ..." again shows the
+	 * correct byteorder - iff we do the following two lines.
+	 *
+	 * Rusty? Help!
+	 */
+	newrange.range[0].min.tcp.port = htons(mr->range[0].min.tcp.port);
+	newrange.range[0].max.tcp.port = htons(mr->range[0].max.tcp.port);
 
 	/* Hand modified range to generic setup. */
 	return ip_nat_setup_info(ct, &newrange, hooknum);

--ELM956090657-7038-0_--