netdev - Re: [PATCH] TCP FIN gets dropped prematurely, results in ack storm

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: <20070501174126.GA7577@2ka.mipt.ru>
Date:	Tue, 1 May 2007 21:41:28 +0400
From:	Evgeniy Polyakov <johnpol@....mipt.ru>
To:	Benjamin LaHaise <bcrl@...ck.org>
Cc:	David Miller <davem@...emloft.net>, netdev@...r.kernel.org
Subject: Re: [PATCH] TCP FIN gets dropped prematurely, results in ack storm

On Tue, May 01, 2007 at 12:49:35PM -0400, Benjamin LaHaise (bcrl@...ck.org) wrote:
> On Tue, May 01, 2007 at 08:20:50PM +0400, Evgeniy Polyakov wrote:
> > > http://www.kvack.org/~bcrl/ack-storm.log .  As near as I can tell, a 
> > > similar effect can occur between two Linux boxes if the right packets get 
> > > reordered/dropped during connection teardown.
> > 
> > Could you archive 24Mb file or cut more precise bits out of it?
> 
> The interesting bits are the first 10 lines.
> 
> > According to your patch, several packets with fin bit might be sent,
> > including one with data. If another host does not receive fin
> > retransmit, then that logic is broken, and it can not be fixed by
> > duplicating fins, I would even say, that remote box should drop second
> > packet with fin, while it can carry data, which will break higher
> > connection logic.
> 
> The FIN hasn't been ack'd by the other side, though and yet Linux is no 
> longer transmitting packets with it sent.  Read the beginning of the trace.

Hmm, 2.2 machine in your test seems to behave incorrectly:

22>11: 2624175182:2624175182(0) ack 1562038077 ack
22>11: 2624175182:2624175182(0) ack 1562038077 fin

11>22: 1562038077:1562038077(0) ack 2624175183 fin
11>22: 1562038077:1562038077(0) ack 2624175183 fin // retransmit after
0.3 seconds, since there was no ack, it was either dropped, or first fin
was dropped in the wire
In former case 22 is in closing, in latter case - fin-wait1

22>11: 2624175182:2624175182(0) ack 1562038077 ack //what is this ack
for? It should have sequence number +1, since fin was sent.
11>22: 1562038078:1562038078(0) ack 2624175183 ack
11 answers that this ack is bogus and it wants 2624175183

22>11: 2624175182:2624175182(0) ack 1562038077 ack
11>22: 1562038078:1562038078(0) ack 2624175183 ack

and so on...

I think if you will storm any system with acks lower than expected
unacknowledged number, result will be the same - ack, that it was bogus
message, if sending system sends wrong ack again, it will again receive
that it was bogus...

-- 
	Evgeniy Polyakov
-
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