netdev - TCP - RST flag

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-next>] [day] [month] [year] [list]

Date:	Tue, 23 Aug 2011 23:31:31 +0300
From:	Daniel Baluta <daniel.baluta@...il.com>
To:	netdev@...r.kernel.org,
	kernelnewbies <kernelnewbies@...nelnewbies.org>
Subject: TCP - RST flag

Hello,

Please help me understanding the behavior of the following
TCP conversation.

You can find bellow a snippet of the (FTP) conversation captured both
on client (C) and server (S).

[client]$ tcpdump  -n  -r client-6-conv.cap
[P1] 49.045690 IP 10.10.0.1.21 > 10.10.0.20.58277: Flags [P.], seq
197:220, ack 81, win 757, length 23
[P2] 49.046600 IP 10.10.0.20.58277 > 10.10.0.1.21: Flags [.], ack 220,
win 738, length 0
[P3] 49.047462 IP 10.10.0.20.58277 > 10.10.0.1.21: Flags [P.], seq
81:87, ack 220, win 738, length 6
[P5] 49.048757 IP 10.10.0.1.21 > 10.10.0.20.58277: Flags [F.], seq
242, ack 87, win 757, length 0
[P6] 49.048794 IP 10.10.0.20.58277 > 10.10.0.1.21: Flags [.], ack 220,
win 738, options [nop,nop,sack 1 {242:243}], length 0
[P4] 49.048801 IP 10.10.0.1.21 > 10.10.0.20.58277: Flags [P.], seq
220:242, ack 87, win 757, length 22
[P7] 49.048833 IP 10.10.0.20.58277 > 10.10.0.1.21: Flags [.], ack 243,
win 715, length 0
[P8] 49.049566 IP 10.10.0.20.58277 > 10.10.0.1.21: Flags [F.], seq 87,
ack 243, win 715, length 0
[P9] 49.050889 IP 10.10.0.1.21 > 10.10.0.20.58277: Flags [R], seq
1672731590, win 0, length 0

[server]$ tcpdump  -n  -r server-6-conv.cap
[P1] 49.059740 IP 10.10.0.1.21 > 10.10.0.20.58277: Flags [P.], seq
197:220, ack 81, win 757, length 23
[P2] 49.061394 IP 10.10.0.20.58277 > 10.10.0.1.21: Flags [.], ack 220,
win 738, length 0
[P3] 49.061760 IP 10.10.0.20.58277 > 10.10.0.1.21: Flags [P.], seq
81:87, ack 220, win 738, length 6
[P4] 49.062794 IP 10.10.0.1.21 > 10.10.0.20.58277: Flags [P.], seq
220:242, ack 87, win 757, length 22
[P5] 49.062843 IP 10.10.0.1.21 > 10.10.0.20.58277: Flags [F.], seq
242, ack 87, win 757, length 0
[P6] 49.063808 IP 10.10.0.20.58277 > 10.10.0.1.21: Flags [.], ack 220,
win 738, options [nop,nop,sack 1 {242:243}], length 0
[P7] 49.063823 IP 10.10.0.20.58277 > 10.10.0.1.21: Flags [.], ack 243,
win 715, length 0
[P8] 49.064271 IP 10.10.0.20.58277 > 10.10.0.1.21: Flags [F.], seq 87,
ack 243, win 715, length 0
[P9] 49.064481 IP 10.10.0.1.21 > 10.10.0.20.58277: Flags [R], seq
1672731590, win 0, length 0

What happens is that servers sends packets P4 and P5, but client
receives P5 before P4.
Since SACK is enabled, client will send a SACK (P6) ack-ing P5.

Then client sees P4, and will send an ack (P7) for P4, then sends P8
with FIN flag set.
What I don't understand, is why server responds with RST (P9) instead of ACK?

This is was obtained on 2.6.32.43. I have also attached full capture files.

I am reading TCP's RFC and kernel code, but so far I haven't reached
a conclusion.

thanks,
Daniel.

Download attachment "server-6-conv.cap" of type "application/octet-stream" (2209 bytes)

Download attachment "client-6-conv.cap" of type "application/octet-stream" (2197 bytes)