netdev - Re: [RFC][PATCH 1/2] TCP: fix lost retransmit detection

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <20071009.152834.38612348.takano@axe-inc.co.jp>
Date:	Tue, 09 Oct 2007 15:28:34 +0900 (JST)
From:	TAKANO Ryousei <takano@...-inc.co.jp>
To:	ilpo.jarvinen@...sinki.fi
Cc:	netdev@...r.kernel.org, y-kodama@...t.go.jp
Subject: Re: [RFC][PATCH 1/2] TCP: fix lost retransmit detection

From: "Ilpo Järvinen" <ilpo.jarvinen@...sinki.fi>
Subject: Re: [RFC][PATCH 1/2] TCP: fix lost retransmit detection
Date: Mon, 8 Oct 2007 14:11:55 +0300 (EEST)

> On Sun, 7 Oct 2007, TAKANO Ryousei wrote:
> 
> > From: "Ilpo Järvinen" <ilpo.jarvinen@...sinki.fi>
> > Subject: Re: [RFC][PATCH 1/2] TCP: fix lost retransmit detection
> > Date: Fri, 5 Oct 2007 13:02:07 +0300 (EEST)
> > 
> > > On Thu, 4 Oct 2007, TAKANO Ryousei wrote:
> > > 
> > > In case sacktag uses fastpath, this code won't be executed for the skb's 
> > > that we would like to check (those with SACKED_RETRANS set, that are 
> > > below the fastpath_skb_hint). We will eventually deal with the whole queue 
> > > when fastpath_skb_hint gets set to NULL, with the next cumulative ACK that 
> > > fully ACKs an skb at the latest. Maybe there's a need for a larger surgery 
> > > than this to fix it. I think we need additional field to tcp_sock to avoid 
> > > doing a full-walk per ACK:
> >
> > I think the problem occurs in slowpath. For example, in case when the receiver
> > detects and sends back a new SACK block, the sender may fail to detect loss
> > of a retransmitted packet.
> 
> ...No, the slow path is very likely to _correct_ the problem! The problem 
> occurs because fastpath _skips_ processing of skbs below fastpath_skb_hint 
> whereas slowpath starts from tcp_write_queue_head. The retransmitted skbs 
> we're interested in reside exactly on that skipped range.
> 
Sorry, my explanaton is insufficient.
This problem occurs even if we are in the slowpath.

For example, consider the case when the state of the retransmission queue is
as shown in Fig.1 (http://projects.gtrc.aist.go.jp/gnet/meeting/sack-bug.html).
There are 13 packets in the retransmission queue, P(0) and P(7) are 
retransmitted, and P(1) to P(9) except P(7) are already SACKed.

If only a SACK block "SACK(8,11)" is received, P(0) is re-transmitted, 
because the ack_seq of P(0) is smaller than the end sequence number (11) 
of the SACK block. However, if the ACK packet has SACK(8,11) and SACK(1,3), 
these SACK blocks are sorted, and SACK(1,3) is process from P(0) to P(2) 
first. In this case, P(0) is not detected as lost because the ack_seq of 
P(0) is not smaller than the end sequence number (3) of this SACK block. 
Next, SACK(8,11) is scanned from P(3) to P(10). P(0) is not checked here, 
and the loss is not detected.

Is it corrent?

Ryousei Takano
-
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