Move tcp_adjust to generic layer

Hi Patrick,

This patch moves tcp_adjust to a generic layer. I sent something similar some time ago but it seems that it got lost.

--
Pablo

Move tcp sequence adjusting to a generic layer.
Status: Tested on 2.6.11-rc5

 include/linux/netfilter_ipv4/ip_nat_protocol.h |    3 
 net/ipv4/netfilter/ip_nat_core.c               |   12 +
 net/ipv4/netfilter/ip_nat_helper.c             |  143 -----------------------
 net/ipv4/netfilter/ip_nat_proto_icmp.c         |    3 
 net/ipv4/netfilter/ip_nat_proto_tcp.c          |  154 ++++++++++++++++++++++++-
 net/ipv4/netfilter/ip_nat_proto_udp.c          |    3 
 net/ipv4/netfilter/ip_nat_proto_unknown.c      |    3 
 7 files changed, 168 insertions(+), 153 deletions(-)

===== include/linux/netfilter_ipv4/ip_nat_protocol.h 1.5 vs edited =====

@@ -43,6 +43,9 @@
 
 	unsigned int (*print_range)(char *buffer,
 				    const struct ip_nat_range *range);
+
+	int (*adjust)(struct sk_buff **pskb, struct ip_conntrack *ct, 
+		      enum ip_conntrack_info ctinfo);
 };
 
 #define MAX_IP_NAT_PROTO 256

===== net/ipv4/netfilter/ip_nat_core.c 1.69 vs edited =====

@@ -358,11 +358,13 @@
 
 	if (test_bit(IPS_SEQ_ADJUST_BIT, &ct->status)
 	    && (hooknum == NF_IP_POST_ROUTING || hooknum == NF_IP_LOCAL_IN)) {
-		DEBUGP("ip_nat_core: adjusting sequence number\n");
-		/* future: put this in a l4-proto specific function,
-		 * and call this function here. */
-		if (!ip_nat_seq_adjust(pskb, ct, ctinfo))
-			return NF_DROP;
+		int proto = (*pskb)->nh.iph->protocol; 
+		struct ip_nat_protocol *protocol = ip_nat_find_proto(proto);
+		if (protocol->adjust != NULL) {
+			DEBUGP("ip_nat_core: adjusting sequence number\n");
+			if (!protocol->adjust(pskb, ct, ctinfo))
+				return NF_DROP;
+		}
 	}
 
 	if (mtype == IP_NAT_MANIP_SRC)

===== net/ipv4/netfilter/ip_nat_helper.c 1.32 vs edited =====

===== net/ipv4/netfilter/ip_nat_proto_icmp.c 1.8 vs edited =====

@@ -111,5 +111,6 @@
     icmp_in_range,
     icmp_unique_tuple,
     icmp_print,
-    icmp_print_range
+    icmp_print_range,
+    NULL
 };

===== net/ipv4/netfilter/ip_nat_proto_tcp.c 1.11 vs edited =====

===== net/ipv4/netfilter/ip_nat_proto_udp.c 1.9 vs edited =====

@@ -161,5 +161,6 @@
     udp_in_range,
     udp_unique_tuple,
     udp_print,
-    udp_print_range
+    udp_print_range,
+    NULL
 };

===== net/ipv4/netfilter/ip_nat_proto_unknown.c 1.7 vs edited =====

@@ -66,5 +66,6 @@
 	unknown_in_range,
 	unknown_unique_tuple,
 	unknown_print,
-	unknown_print_range
+	unknown_print_range,
+	NULL
 };

IIRC the argument against this patch was that it is entirely specific to TCP. Can't we simply move it all to TCP's manip_pkt() function ?

Regards
Patrick

Thinking about it, this would also allow to solve a differnt issue nicely. TCP packets contained in ICMP errors don't have their sequence numbers adjusted backwards, theoretically this can cause them to be discarded by the receipient. It would require an additional argument to manip_pkt, for ICMP packets we can't simply apply the adjustment of the reverse direction, but need to apply it inversely. Perhaps it can also be deduced from iphdroff and skb->nh.iph. What do you think ?

Regards
Patrick