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

[Xen-devel] skb_checksum_setup and NAT


  • To: Xen Devel <xen-devel@xxxxxxxxxxxxxxxxxxx>
  • From: Christophe Saout <christophe@xxxxxxxx>
  • Date: Thu, 28 Sep 2006 18:12:39 +0200
  • Delivery-date: Thu, 28 Sep 2006 09:13:20 -0700
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>

Hello,

skb_checksum_setup/proto_csum_blank are causing a terrible mess with
NAT. I just spent several hours debugging why passive FTP ip/port
packets arrived on the client with a wrong TCP checksum. This also
happens for all subsequent packets where the tcp sequence has to be
changed.

It turns out that ip_nat_mangle_tcp computes the whole checksum and then
dev_queue_xmit decides to compute it a second time and messes it up.

My network setup in Dom0 is as follows:

DomU/vif#.0 - xenbr0 - vif0.0/int0 - NAT/routing - eth0 (real)

Apart from that I already had to add nf_reset to the loopback code (for
vif0.0/int0) in order to get NAT working at all (see
http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=746 ), the
packets arriving at the NAT code have proto_csum_blank set all the way
from the DomU.

Why do you need this mess? Isn't the normal ip_summed sufficient? The
patches don't contain any annotations.

It's not funny having to mess around in the NAT code. I can fix it up by
adding even more #ifdef CONFIG_XEN to ignore all fixups related to the
anything else than the 12 byte tcpudp magic, but I don't think this is a
nice solution at all.



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


 


Rackspace

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