[NETFILTER]: IRC Zero Port Fix

Ian Kumlien reported that new NAT code started sending out DCC
requests with 0 as the IP address.  That prompted me to write a simple
IRC test case, which both illustrated the bug, and found another one
in that the wrong expectation was being set up when NAT occurred.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Signed-off-by: David S. Miller <davem@davemloft.net>

net/ipv4/netfilter/ip_conntrack_irc.c

@@ -209,9 +209,14 @@ static int help(struct sk_buff **pskb,
 			DEBUGP("tcph->seq = %u\n", th->seq);
 			seq = ntohl(th->seq) + (addr_beg_p - ib_ptr);
 
+			/* We refer to the reverse direction ("!dir")
+			 * tuples here, because we're expecting
+			 * something in the other * direction.
+			 * Doesn't matter unless NAT is happening.  */
 			exp->tuple = ((struct ip_conntrack_tuple)
 				{ { 0, { 0 } },
-				  { ct->tuplehash[dir].tuple.src.ip, { .tcp = { htons(dcc_port) } },
+				  { ct->tuplehash[!dir].tuple.dst.ip,
+				    { .tcp = { htons(dcc_port) } },
 				    IPPROTO_TCP }});
 			exp->mask = ((struct ip_conntrack_tuple)
 				{ { 0, { 0 } },

net/ipv4/netfilter/ip_nat_irc.c

@@ -83,7 +83,10 @@ static unsigned int help(struct sk_buff **pskb,
 	 *              0x01, \n:  terminators
 	 */
 
-	sprintf(buffer, "%u %u", ntohl(exp->tuple.src.ip), port);
+	/* AAA = "us", ie. where server normally talks to. */
+	sprintf(buffer, "%u %u",
+		ntohl(exp->master->tuplehash[IP_CT_DIR_REPLY].tuple.dst.ip),
+		port);
 	DEBUGP("ip_nat_irc: Inserting '%s' == %u.%u.%u.%u, port %u\n",
 	       buffer, NIPQUAD(exp->tuple.src.ip), port);