[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

  • To: "Jon Mason" <jdmason@xxxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxx>
  • 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
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • 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.]


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.