lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Mon, 27 Oct 2014 00:23:14 +0200
From:	Or Gerlitz <>
To:	Tom Herbert <>
Cc:	Or Gerlitz <>,
	"" <>,
	John Fastabend <>,
	Jeff Kirsher <>
Subject: Re: some failures with vxlan offloads..

On Sun, Oct 26, 2014 at 5:29 PM, Tom Herbert <> wrote:
> On Sun, Oct 26, 2014 at 6:36 AM, Or Gerlitz <> wrote:

>> In the cases where it breaks I can see
>>         UDP: bad checksum. From to
>> ulen 726
>> prints from __udp4_lib_rcv() in the kernel log of the node where offloads
>> are OFF, where the bad packet is sent from the host where offloading is
>> enabled. I guess the packet is just dropped:

> Can you determine what the TSO HW engine is setting in UDP checksum
> field? tcpdump -vv might be able to show this. The symptoms seem to
> indicate that it may not be zero.

Thanks for the quick response. I'll check what is placed in the UDP
checksum field for packets that went through the offloading HW and let
you know.

BTW, if following the direction you proposed, I wonder why this works
(e.g the kernel doesn't drops the encapsulated TCP packets) when both
sides are offloaded?

Tomorrow (Monday) I am OOO so will be able to do these further tests Tuesday.

To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to
More majordomo info at

Powered by blists - more mailing lists