From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nivedita Singhvi Subject: Re: Xen checksumming bug with IPsec ESP packets Date: Thu, 04 Aug 2005 18:03:18 -0700 Message-ID: <42F2BAD6.3020400@comcast.net> References: <42F0F054.9030003@cmu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Keir Fraser Cc: caceres@us.ibm.com, xen-devel@lists.xensource.com, "Jonathan M. McCune" , jaegert@us.ibm.com, sailer@us.ibm.com List-Id: xen-devel@lists.xenproject.org Keir Fraser wrote: > > On 3 Aug 2005, at 17:27, Jonathan M. McCune wrote: > >> We fixed this by removing the addition of flag NETIF_F_IP_CSUM in >> drivers/xen/netfront/netfront.c:create_netdev(). I believe this tells >> the kernel to just always do the checksum in software. Thus, the >> broken optimization for TCP/UDP packets gets bypassed. >> >> >> Permanent Solution: >> >> ??? >> >> That's why I posted this message... :-) > > > I suspect the ESP code would need to be made aware of the csum_blank > field, and fill in before forwarding. There are doubtless other paths > that may need similar tweaks (e.g., NAT IP masquerading is untested I > think, although there's a fair chance it'll just work). > > Apart from the above 'proper fix', simple not-so-hacky solutions include: > * Run 'ethtool -K tx off' in each domU > * Add an option to netback in domain0 to fill in checksums itself if > not done by domU. > * Allow netback to advertise to domUs whether it accepts > non-checksummed packets, and have an option to set this advertisement > when you start netback. Keir, Jonathan, I stuck the above in a bugzilla entry (#143) just for better tracking. Jonathan, would you be able to test patches? thanks, Nivedita