linux-kernel - Re: TCP SACK issue, hung connection, tcpdump included

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

Message-ID: <46ACCEEB.2070500@netbauds.net>
Date:	Sun, 29 Jul 2007 18:31:23 +0100
From:	"Darryl L. Miles" <darryl-mailinglists@...bauds.net>
To:	linux-kernel@...r.kernel.org
Subject: Re: TCP SACK issue, hung connection, tcpdump included

This is a reproducible problem (would take me between 30 mins and a day 
to reproduce it).  Please feel free to provide me with tcpdump options 
to be sure I include to get the information you need.

I've been informed there is no firewall at all, the only firewalling 
that takes place is the local Linux netfilter, I've never audited the 
kit at the SERVER end to know for sure.

I have run a tcpdump from the server side before now (not for the 
tcpdump I enclosed) when try to diagnose the problem in the first place 
and the triplet of packets:

09:28:11.331256 IP SERVER.ssh > CLIENT.50727: . 12408:13856(1448) ack 2991 win 2728 <nop,nop,timestamp 8084763 800001749>
09:28:11.331354 IP CLIENT.50727 > SERVER.ssh: . ack 18464 win 378 <nop,nop,timestamp 800099704 7692910,nop,nop,sack sack 1 {12408:13856} >
09:28:44.286495 IP CLIENT.50727 > SERVER.ssh: P 2991:3039(48) ack 18464 win 378 <nop,nop,timestamp 800107942 7692910>

That keeps repeating from that point in was observable at both sides.  
No checksum errors have ever been shown on any tcpdump I saw.

The dump I posted was the first dump I was able to reliably reproduce 
(observing from the CLIENT end), I'm pretty sure given some time 
tomorrow I could create you 2 dumps of the same session (the view from 
each end).   Looking a little more at the dump today I see that at time 
index 09:21:39.860245 to server sends data from seq 12408:13856 again.  
Here is a snippet that backs up a little more around the time the 
trouble starts, as SERVER send sequence 12408 seems to be the problem 
maybe I need to illustrate what happened when that sequence was first sent.

Excuse my understanding if it seems a bit limited.  SACK is only used 
when segments are dropped and from inspecting the dump I can't spot 
where a lost segment occurs.  My main question is why does the CLIENT 
ack data 12408:13856 and beyond all the way up to 18464 (@ 
09:21:39.490775) and then start to SACK {12408:13856} (@ 09:21:39.860302) ?

Does this mean the client is the buggy end for going back on data it has 
already acked cleanly, that would be my interpretation of events.

Enclosed should be a tcpdump with -vvS of the same session as before 
observing from the client side.

I hope I've answered all the points raised in this thread.

Darryl

View attachment "linux.tcpdump.txt" of type "text/plain" (39038 bytes)