netdev - Re: [PATCH] tcp: fixing TLP's FIN recovery

lists.openwall.net		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]

Message-ID: <1402326259.3645.374.camel@edumazet-glaptop2.roam.corp.google.com>
Date:	Mon, 09 Jun 2014 08:04:19 -0700
From:	Eric Dumazet <eric.dumazet@...il.com>
To:	Per Hurtig <per.hurtig@....se>
Cc:	Nandita Dukkipati <nanditad@...gle.com>,
	Netdev <netdev@...r.kernel.org>,
	Anna Brunström <anna.brunstrom@....se>,
	mohammad.rajiullah@....se, Neal Cardwell <ncardwell@...gle.com>,
	Sergei Shtylyov <sergei.shtylyov@...entembedded.com>
Subject: Re: [PATCH] tcp: fixing TLP's FIN recovery

On Mon, 2014-06-09 at 16:42 +0200, Per Hurtig wrote:
> Tried to run the script, but I don't have the "common/defaults" and the 
> test scripts from the git repository fails on all TCP tests for Linux. 
> The results I listed in the enclosed packet traces are from two real 
> machines communicating with each other (with fresh net-next kernels and 
> TLP without the zero probe check), so I tend to rely more on those 
> results.

Do not top post on netdev.

We at Google run about 1000 packet drill tests for any functional change
in TCP stack. This is the only way we can scale.

We are not 'studying by hand' various tcpdumps when a tool can do it
properly.

Nandita asked you give a pointer to the source code explaining how fast
retransmit was done for this specific case, but you provided a tcpdump,
which hardly can be reproduced and be the answer to the question.

So now, we are trying to have a test to reproduce the issue and check
the fix is complete.

So far, I am not really convinced. It seems the FIN _is_ retransmitted,
but I do not see the SACK for this RTX is properly handled in time.

Its one thing checking the FIN is retransmitted, its another to check
that the SACK will trigger sensible behavior.

If you carefully check your tcpdump, you'll see there is the same
problem, and you missed it, while packetdrill exactly pointed it.

Thanks

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html