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@lists.xensource.com http://lists.xensource.com/xen-devel
On 28/9/06 17:12, "Christophe Saout" <christophe@saout.de> wrote:> Why do you need this mess? Isn''t the normal ip_summed sufficient? The > patches don''t contain any annotations.The Linux network stack doesn''t expect to be able to receive packets that have their protocol-checksum field empty. So we have to add extra packet flags to signal this situation. It does create something of a mess unless all parts of the network stack know what''s going on. I heard that the networking maintainers were working on a more generic scheme that we should be able to make use of. Apart from that, the stack needs to make sure that the proto_csum_blank field is cleared whenever it fills in the full checksum. For now, if it causes you problems and you just want stuff to work, you can run ethtool on your interface in domU: ''ethtool -K eth0 tx off''. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Am Donnerstag, den 28.09.2006, 18:35 +0100 schrieb Keir Fraser:> The Linux network stack doesn''t expect to be able to receive packets that > have their protocol-checksum field empty. So we have to add extra packet > flags to signal this situation. It does create something of a mess unless > all parts of the network stack know what''s going on. I heard that the > networking maintainers were working on a more generic scheme that we should > be able to make use of. Apart from that, the stack needs to make sure that > the proto_csum_blank field is cleared whenever it fills in the full > checksum.Ok, ip_forward e.g. sets ip_summed to CHECKSUM_NONE, so it indeed assumes the checksum is correctly set. This should probably just be changed accordingly to set CHECKSUM_HW when the incoming packet didn''t have a valid checksum set (although the packet was accepted), possibly by adding a new CHECKSUM_xxx define. You are probably talking about the work by Patrick McHardy that is being merged for post-2.6.18: http://www.kernel.org/git/?p=linux%2Fkernel%2Fgit%2Ftorvalds%2Flinux-2.6.git&a=search&h=HEAD&s=checksum It looks promising though it doesn''t seem to address this problem in particular (?).> For now, if it causes you problems and you just want stuff to work, you can > run ethtool on your interface in domU: ''ethtool -K eth0 tx off''.I just ifdef''ed all places where the NAT code changed the checksum. I''m having a lot of network traffic between DomU''s and I''d like to keep CPU usage down. If someone is interested in the patch, it''s attached (just the FTP NAT part tested though). _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Christophe Saout <christophe@saout.de> wrote:> > You are probably talking about the work by Patrick McHardy that is being > merged for post-2.6.18: > > http://www.kernel.org/git/?p=linux%2Fkernel%2Fgit%2Ftorvalds%2Flinux-2.6.git&a=search&h=HEAD&s=checksum > > It looks promising though it doesn''t seem to address this problem in > particular (?).This is the basis for a solution. Once CHECKSUM_HW is split into the TX and RX variants, you can then use them directly in the stack which allows us to accept packets with partial checksums. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel