On Fri, 2017-01-13 at 12:28 -0500, Jason Baron wrote:
> i,
>
> (Re-sending - seems like my reply was lost)
>
> I wanted to define this condition as narrowly as I could. I'm ok
> dropping it -
> I'm not sure its going to make much difference in practice. So to that end,
> dropping this extra check
On 01/11/2017 10:48 AM, Eric Dumazet wrote:
> On Thu, 2017-01-05 at 16:33 -0500, Jason Baron wrote:
>
>>
>> +/* Accept RST for rcv_nxt - 1 after a FIN.
>> + * When tcp connections are abruptly terminated from Mac OSX (via ^C), a
>> + * FIN is sent followed by a RST packet. The RST is sent with t
On Thu, 2017-01-05 at 16:33 -0500, Jason Baron wrote:
>
> +/* Accept RST for rcv_nxt - 1 after a FIN.
> + * When tcp connections are abruptly terminated from Mac OSX (via ^C), a
> + * FIN is sent followed by a RST packet. The RST is sent with the same
> + * sequence number as the FIN, and thus a
On 01/11/2017 12:17 AM, Christoph Paasch wrote:
Hello Jason,
(resending as Gmail sent out with HTML)
On 05/01/17 - 16:33:28, Jason Baron wrote:
Using a Mac OSX box as a client connecting to a Linux server, we have found
that when certain applications (such as 'ab'), are abruptly terminated
(vi
Hello Jason,
(resending as Gmail sent out with HTML)
On 05/01/17 - 16:33:28, Jason Baron wrote:
> Using a Mac OSX box as a client connecting to a Linux server, we have found
> that when certain applications (such as 'ab'), are abruptly terminated
> (via ^C), a FIN is sent followed by a RST packet
Using a Mac OSX box as a client connecting to a Linux server, we have found
that when certain applications (such as 'ab'), are abruptly terminated
(via ^C), a FIN is sent followed by a RST packet on tcp connections. The
FIN is accepted by the Linux stack but the RST is sent with the same
sequence n
