netdev - Re: [PATCH 1/2] [TCP]: Process DSACKs that reside within a SACK block

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: <20071031.025104.37987469.davem@davemloft.net>
Date:	Wed, 31 Oct 2007 02:51:04 -0700 (PDT)
From:	David Miller <davem@...emloft.net>
To:	ilpo.jarvinen@...sinki.fi
Cc:	netdev@...r.kernel.org
Subject: Re: [PATCH 1/2] [TCP]: Process DSACKs that reside within a SACK
 block

From: "Ilpo_Järvinen" <ilpo.jarvinen@...sinki.fi>
Date: Wed, 31 Oct 2007 11:48:31 +0200 (EET)

> DSACK inside another SACK block were missed if start_seq of DSACK
> was larger than SACK block's because sorting prioritizes full
> processing of the SACK block before DSACK. After SACK block
> sorting situation is like this:
> 
>              SSSSSSSSS
>                   D
>                         SSSSSS
>                                SSSSSSS
> 
> Because write_queue is walked in-order, when the first SACK block
> has been processed, TCP is already past the skb for which the
> DSACK arrived and we haven't taught it to backtrack (nor should
> we), so TCP just continues processing by going to the next SACK
> block after the DSACK (if any).
> 
> Whenever such DSACK is present, do an embedded checking during
> the previous SACK block.
> 
> If the DSACK is below snd_una, there won't be overlapping SACK
> block, and thus no problem in that case. Also if start_seq of
> the DSACK is equal to the actual block, it will be processed
> first.
> 
> Tested this by using netem to duplicate 15% of packets, and
> by printing SACK block when found_dup_sack is true and the 
> selected skb in the dup_sack = 1 branch (if taken):
> 
>   SACK block 0: 4344-5792 (relative to snd_una 2019137317)
>   SACK block 1: 4344-5792 (relative to snd_una 2019137317) 
> 
> equal start seqnos => next_dup = 0, dup_sack = 1 won't occur...
> 
>   SACK block 0: 5792-7240 (relative to snd_una 2019214061)
>   SACK block 1: 2896-7240 (relative to snd_una 2019214061)
>   DSACK skb match 5792-7240 (relative to snd_una)
> 
> ...and next_dup = 1 case (after the not shown start_seq sort),
> went to dup_sack = 1 branch.
> 
> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@...sinki.fi>

I will queue this bug fix up, thanks Ilpo!

And thanks for all of the testing information, it helps review
enormously.
-
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