WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

RE: [Xen-devel] [PATCH] Fix NAT for domU checksum offload

To: "Jon Mason" <jdmason@xxxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: RE: [Xen-devel] [PATCH] Fix NAT for domU checksum offload
From: "Ian Pratt" <m+Ian.Pratt@xxxxxxxxxxxx>
Date: Sat, 15 Oct 2005 00:09:36 +0100
Delivery-date: Fri, 14 Oct 2005 23:07:01 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcXRD28nhYeF/HOKSZ2ffXCeQEyeWgABDTyw
Thread-topic: [Xen-devel] [PATCH] Fix NAT for domU checksum offload
> Below is a fix for the current problem of checksum offload 
> not working in a NAT'ed network.  The cause is the 
> NAT/iptables code incorrectly modifying the TCP/UDP checksum 
> (for the checksum offload case).  The original code assumes a 
> valid checksum, which is not the case for checksum offload 
> packets (which has a complimented, partial checksum for the 
> hardware to use).  The fix is to compliment the new address 
> and not compliment the old address (which is complimented in 
> the partial checksum), and roll that with the 
> ip_nat_cheat_check function.

Thanks for looking into this -- this issue has been nagging away for a
long time.
 
> There are two "versions" of the patch below.  The first 
> version is a diff to show the actual changes made to the 
> ip_nat_proto_udp.c and ip_nat_proto_tcp.c file (as it is 
> difficult/impossible to tell from the second patch).  The 
> second version is the one to commit to the tree (which 
> creates 2 new files in the sparse directory).

Would we be better off committing the first patch to the patches
directory rather than adding to the sparse tree.

Do you think you could send this upstream via davem?

[Today has been a good day for vanquishing bugs. We're working on a few
save/restore fixes and have a list of tools issues, but 32bit isn't in
too bad shape right now.]

Ian



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel