ip_nat_mangle_udp_packet() updated

Hello Harald and all.

Find attached an updated patch for my ip_nat_mangle_udp_packet(). This function no longer gratuitously checkums the mangled UDP packet. It only calculated a UDP checksum when the pre-mangling checksum is non-zero. It still pushes the packet up for IP checksum however. I believe this to be the correct way to do this.

Thanx,
b.

Brian J. Murrell

diff -Nur --exclude '*~' --exclude '*.orig' linux-2.4.19-16mdk/include/linux/netfilter_ipv4/ip_nat_helper.h linux-2.4.19-16mdk.tmp/include/linux/netfilter_ipv4/ip_nat_helper.h
@@ -50,6 +50,13 @@
 				unsigned int match_len,
 				char *rep_buffer,
 				unsigned int rep_len);
+extern int ip_nat_mangle_udp_packet(struct sk_buff **skb,
+				struct ip_conntrack *ct,
+				enum ip_conntrack_info ctinfo,
+				unsigned int match_offset,
+				unsigned int match_len,
+				char *rep_buffer,
+				unsigned int rep_len);
 extern int ip_nat_seq_adjust(struct sk_buff *skb,
 				struct ip_conntrack *ct,
 				enum ip_conntrack_info ctinfo);

diff -Nur --exclude '*~' --exclude '*.orig' linux-2.4.19-16mdk/net/ipv4/netfilter/ip_nat_standalone.c linux-2.4.19-16mdk.tmp/net/ipv4/netfilter/ip_nat_standalone.c
@@ -358,5 +358,6 @@
 EXPORT_SYMBOL(ip_nat_helper_unregister);
 EXPORT_SYMBOL(ip_nat_cheat_check);
 EXPORT_SYMBOL(ip_nat_mangle_tcp_packet);
+EXPORT_SYMBOL(ip_nat_mangle_udp_packet);
 EXPORT_SYMBOL(ip_nat_used_tuple);
 MODULE_LICENSE("GPL");

Binary files linux-2.4.19-16mdk/net/ipv4/netfilter/.ip_nat_standalone.c.swp and linux-2.4.19-16mdk.tmp/net/ipv4/netfilter/.ip_nat_standalone.c.swp differ

Hello,

As it was reported several times on the mailing list, the tcp window tracking patch could cause long SMTP delays in some cases.

After dumping a lot of traffic and replaying the streams it turned out that the book-keeping inside the patch could go out of sync when SACK was used. In another words, SACK was not supported by the patch and it could cause legitimate packets to be blocked.

I have committed the new tcp-window-tracking.patch with SACK support in the cvs.

It'd be very helpful if sites which experienced the long SMTP delays could give a try to the new version of the patch and then send a report: 'yeah, it's seems to be OK' or 'nope, still bad'. :-)

Best regards,
Jozsef
-
E-mail : [email protected], [email protected] PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : KFKI Research Institute for Particle and Nuclear Physics

          H-1525 Budapest 114, POB. 49, Hungary

Mmmh.. I see.

great, thanks.

well, I'd rather not test it on kashyyyk.netfilter.org for some time... so I really have to rely on others for testing. Please tell me about your erxperience with this new patch.

Live long and prosper
- Harald Welte / [email protected]               http://www.gnumonks.org/
============================================================================
GCS/E/IT d- s-: a-- C+++ UL++++$ P+++ L++++$ E--- W- N++ o? K- w--- O- M- 
V-- PS+ PE-- Y+ PGP++ t++ 5-- !X !R tv-- b+++ DI? !D G+ e* h+ r% y+(*)

Hello,

First I wasn't able to reproduce it on a normal box with low traffic but then I asked our management if I could test it out on one of our main packetfilters and after 3 minutes I saw those strange DROPs and retransmits with interesting TCP flag combinations indicating the SACK. While this firewall has a steady 30Mbit/s
sustained filtering rate 7/24 with 8 interfaces and around 1200 rules, I
expected some rules not to work because not only did I use the tcp window tracking patch but the packetfilter was still running ipchains with a 2.2.x kernel.

To get to the point: All rules were transitioned (I added the MetaFW layer for iptables to our fw suite) and worked very well but the SMTP ones somehow generated too many DROPs. I accredit this to the missing SACK support in the tcp window tracking patch. I wasn't able to tcpdump nor trace packets back in another way because of strict security constraints (don't ask).

Actually you should, because the problem will be spotted very soon and you can then quickly failback to the old kernel without pissing off too many people.

I will now (after I have more or less proven that without this SACK patch we're running into problems too) patch my kernel and try it again. Unfortunately I have only a very limited test period because if I screw up 30 fulltime engineers won't be able to work properly. My initial test which only lasted for 20 minutes cost us around $4000. I will report back as soon as I have done testing with this new patch.

Regards,
Roberto Nibali, ratz

echo '[q]sa[ln0=aln256%Pln256/snlbx]sb3135071790101768542287578439snlbxq' | dc

Sucess report:

Unpatched kernel : A lot of DROPs
Patched kernel (SACK support) : _No_ DROPs which are illicit drops.

I've run the new packet filter for 16 hours and I am now evaluating 1.2Gbytes of logfiles. So far it looks good. It has cured the obvious problems I've had with the initial tcp window tracking patch.

I see now however, that there is still one open report from Brian.

Thanks,
Roberto Nibali, ratz

echo '[q]sa[ln0=aln256%Pln256/snlbx]sb3135071790101768542287578439snlbxq' | dc

Actually, I sent a second one to Jozsef by private mail just the other day.

b.

Brian J. Murrell

This patch looks fine to me. I will put it into the pending repository of patch-o-matic.

Thank you!

Live long and prosper
- Harald Welte / [email protected]               http://www.gnumonks.org/
============================================================================
GCS/E/IT d- s-: a-- C+++ UL++++$ P+++ L++++$ E--- W- N++ o? K- w--- O- M- 
V-- PS+ PE-- Y+ PGP++ t++ 5-- !X !R tv-- b+++ DI? !D G+ e* h+ r% y+(*)