From: Eric Dumazet
Date: Thu, 25 May 2017 09:50:51 -0700
> On Thu, 2017-05-25 at 12:48 -0400, David Miller wrote:
>> From: Eric Dumazet
>> Date: Tue, 23 May 2017 15:24:46 -0700
>>
>> > Add a FLAG_NO_CHALLENGE_ACK so that tcp_rcv_state_process()
>> > can choose to send a challenge ACK and discar
On Thu, 2017-05-25 at 12:48 -0400, David Miller wrote:
> From: Eric Dumazet
> Date: Tue, 23 May 2017 15:24:46 -0700
>
> > Add a FLAG_NO_CHALLENGE_ACK so that tcp_rcv_state_process()
> > can choose to send a challenge ACK and discard the packet instead
> > of wrongly change socket state.
>
> Appl
From: Eric Dumazet
Date: Tue, 23 May 2017 15:24:46 -0700
> Add a FLAG_NO_CHALLENGE_ACK so that tcp_rcv_state_process()
> can choose to send a challenge ACK and discard the packet instead
> of wrongly change socket state.
Applied, but the tests end up being double-negatives so it might
have been
From: Eric Dumazet
Paul Fiterau Brostean reported :
Linux TCP stack we analyze exhibits behavior that seems odd to me.
The scenario is as follows (all packets have empty payloads, no window
scaling, rcv/snd window size should not be a factor):
TEST HARNESS (CLIENT)
