upted ESP packets and
increase XfrmInStateProtoError counter in /proc/net/xfrm_stat.
3. iperf UDP test from the VM with packet sizes above MTU will not work at
all.
4. iperf TCP test from the VM will get ridiculously low performance because.
Signed-off-by: Ansis Atteka
Co-authored-by: St
On 20 April 2017 at 02:47, Steffen Klassert
wrote:
> On Tue, Apr 18, 2017 at 07:10:03PM -0700, Ansis Atteka wrote:
>>
>> However, after taking pointers from your patch I came up with this one
>> that may solve this problem once and for all (note, that I was seeing
>> t
On 18 April 2017 at 02:09, Steffen Klassert
wrote:
> On Thu, Apr 13, 2017 at 07:45:08PM -0700, Ansis Atteka wrote:
>> On 11 April 2017 at 00:07, Steffen Klassert
>> wrote:
>> >
>> > What's wrong with the checksum provided by the GSO layer and
>> &
On 13 April 2017 at 19:45, Ansis Atteka wrote:
>
>
>
> On 11 April 2017 at 00:07, Steffen Klassert
> wrote:
>>
>> On Mon, Apr 10, 2017 at 11:42:07AM -0700, Ansis Atteka wrote:
>> > Otherwise, if L4 checksum calculation is done after encryption,
>> >
will drop all the corrupted ESP packets, hence UDP iperf test
with large packets will fail completely or TCP iperf will get ridiculously
low performance because TCP window will never grow above MTU.
Signed-off-by: Ansis Atteka
---
net/xfrm/xfrm_output.c | 19 +--
1 file change
On Sat, Dec 31, 2016 at 4:07 PM, Ansis Atteka wrote:
> On Wed, Nov 30, 2016 at 3:58 AM, Hayes Wang wrote:
>> Mark Lord
>> [...]
>>> > Not sure why, because there really is no other way for the data to
>>> > appear where it does at the beginning of that U
On Wed, Nov 30, 2016 at 3:58 AM, Hayes Wang wrote:
> Mark Lord
> [...]
>> > Not sure why, because there really is no other way for the data to
>> > appear where it does at the beginning of that URB buffer.
>> >
>> > This does seem a rather unexpected burden to place upon someone
>> > reporting a
