Re: question about linux tcp request queue handling

From: "Paul Albrecht" <palbrecht@qwest.net>
To: "Andi Kleen" <ak@suse.de>
Cc: niv@us.ibm.com, linux-kernel@vger.kernel.org,
	"netdev" <netdev@oss.sgi.com>
Subject: Re: question about linux tcp request queue handling
Date: Tue, 8 Jul 2003 12:23:37 -0700	[thread overview]
Message-ID: <001401c34586$6f955e20$6801a8c0@oemcomputer> (raw)
In-Reply-To: p73fzliqa91.fsf@oldwotan.suse.de

[-- Attachment #1: Type: text/plain, Size: 655 bytes --]

Andi Kleen writes:

>
> The 4.4BSD-Lite code described in Stevens is long outdated. All modern
> BSDs (and probably most other Unixes too) do it in a similar way to what
> Nivedita described. The keywords are "syn flood attack" and "DoS".
>

I have attached a copy of tcpdump output for two linux systems connected
over ether replaying the scenario for incoming request queue handling given
in Stevens's TCP/IP Illustrated Volume 1: The Protocols.  What I don't
understand about the third handshake is if the server is going to send the
syn/ack in response the client's initial syn then why does server repeatly
ignore the subsequent ack from the client?

[-- Attachment #2: trace.txt --]
[-- Type: text/plain, Size: 2723 bytes --]

01:12:09.622208 client.acme.net.1024 > server.acme.net.7777: S 2730884988:2730884988(0) win 5840 <mss 1460,sackOK,timestamp 133507 0,nop,wscale 0> (DF)
01:12:09.623457 server.acme.net.7777 > client.acme.net.1024: S 1682786145:1682786145(0) ack 2730884989 win 5792 <mss 1460,sackOK,timestamp 42960 133507,nop,wscale 0> (DF)
01:12:09.623963 client.acme.net.1024 > server.acme.net.7777: . ack 1682786146 win 5840 <nop,nop,timestamp 133508 42960> (DF)
01:12:11.858191 client.acme.net.1025 > server.acme.net.7777: S 2743503110:2743503110(0) win 5840 <mss 1460,sackOK,timestamp 134652 0,nop,wscale 0> (DF)
01:12:11.858991 server.acme.net.7777 > client.acme.net.1025: S 1690738882:1690738882(0) ack 2743503111 win 5792 <mss 1460,sackOK,timestamp 43183 134652,nop,wscale 0> (DF)
01:12:11.859535 client.acme.net.1025 > server.acme.net.7777: . ack 1690738883 win 5840 <nop,nop,timestamp 134653 43183> (DF)
01:12:13.909895 client.acme.net.1026 > server.acme.net.7777: S 2736891141:2736891141(0) win 5840 <mss 1460,sackOK,timestamp 135702 0,nop,wscale 0> (DF)
01:12:13.910636 server.acme.net.7777 > client.acme.net.1026: S 1692403887:1692403887(0) ack 2736891142 win 5792 <mss 1460,sackOK,timestamp 43388 135702,nop,wscale 0> (DF)
01:12:13.911144 client.acme.net.1026 > server.acme.net.7777: . ack 1692403888 win 5840 <nop,nop,timestamp 135703 43388> (DF)
01:12:17.502319 server.acme.net.7777 > client.acme.net.1026: S 1692403887:1692403887(0) ack 2736891142 win 5792 <mss 1460,sackOK,timestamp 43748 135703,nop,wscale 0> (DF)
01:12:17.502909 client.acme.net.1026 > server.acme.net.7777: . ack 1692403888 win 5840 <nop,nop,timestamp 137542 43748,nop,nop,sack sack 1 {1692403887:1692403888} > (DF)
01:12:23.502350 server.acme.net.7777 > client.acme.net.1026: S 1692403887:1692403887(0) ack 2736891142 win 5792 <mss 1460,sackOK,timestamp 44348 137542,nop,wscale 0> (DF)
01:12:23.502969 client.acme.net.1026 > server.acme.net.7777: . ack 1692403888 win 5840 <nop,nop,timestamp 140614 44348,nop,nop,sack sack 1 {1692403887:1692403888} > (DF)
01:12:35.702302 server.acme.net.7777 > client.acme.net.1026: S 1692403887:1692403887(0) ack 2736891142 win 5792 <mss 1460,sackOK,timestamp 45568 140614,nop,wscale 0> (DF)
01:12:35.702840 client.acme.net.1026 > server.acme.net.7777: . ack 1692403888 win 5840 <nop,nop,timestamp 146859 45568,nop,nop,sack sack 1 {1692403887:1692403888} > (DF)
01:12:59.702343 server.acme.net.7777 > client.acme.net.1026: S 1692403887:1692403887(0) ack 2736891142 win 5792 <mss 1460,sackOK,timestamp 47968 146859,nop,wscale 0> (DF)
01:12:59.702994 client.acme.net.1026 > server.acme.net.7777: . ack 1692403888 win 5840 <nop,nop,timestamp 159147 47968,nop,nop,sack sack 1 {1692403887:1692403888} > (DF)