From mboxrd@z Thu Jan 1 00:00:00 1970 From: Vladislav Yasevich Subject: Re: [PATCHv2] sctp: Enforce retransmission limit during shutdown Date: Wed, 06 Jul 2011 12:23:50 -0400 Message-ID: <4E148C16.8090505@hp.com> References: <20110629143649.GC10085@canuck.infradead.org> <4E0B3DA1.9060200@hp.com> <20110629154814.GD10085@canuck.infradead.org> <4E0B4F71.4020108@hp.com> <20110630084933.GA24074@canuck.infradead.org> <4E0C8368.5090502@hp.com> <20110704135019.GA801@canuck.infradead.org> <4E146652.7010205@hp.com> <20110706141808.GA17652@canuck.infradead.org> <4E1471DC.2090407@hp.com> <20110706154900.GB17652@canuck.infradead.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit To: netdev@vger.kernel.org, davem@davemloft.net, Wei Yongjun , Sridhar Samudrala , linux-sctp@vger.kernel.org Return-path: Received: from g1t0028.austin.hp.com ([15.216.28.35]:2110 "EHLO g1t0028.austin.hp.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753546Ab1GFQX4 (ORCPT ); Wed, 6 Jul 2011 12:23:56 -0400 In-Reply-To: <20110706154900.GB17652@canuck.infradead.org> Sender: netdev-owner@vger.kernel.org List-ID: On 07/06/2011 11:49 AM, Thomas Graf wrote: > On Wed, Jul 06, 2011 at 10:31:56AM -0400, Vladislav Yasevich wrote: >>>>> + * >>>>> + * Allow the association to timeout if SHUTDOWN is >>>>> + * pending in case the receiver stays in zero window >>>>> + * mode forever. >>>>> */ >>>>> if (!q->asoc->peer.rwnd && >>>>> !list_empty(&tlist) && >>>>> - (sack_ctsn+2 == q->asoc->next_tsn)) { >>>>> + (sack_ctsn+2 == q->asoc->next_tsn) && >>>>> + !(q->asoc->state >= SCTP_STATE_SHUTDOWN_PENDING)) { >>>> >>>> Would a test for (q->asoc->state != SCTP_STATE_SHUTDOWN_PENDING) be clearer? We only >>>> care about the PENDING state here. >>> >>> I think SHUTDOWN_RECEIVED should also be included. We continue to transmit and >>> process SACKs after receiving a SHUTDOWN. >> >> I am not sure about SHUTDOWN_RECEIVED. If we received shutdown, then we are not in >> a 0 window situation. Additionally, the sender of the SHUTDOWN started the GUARD timer >> and will abort after it expires. So there is no special handling on our part. > > Why can't we be in a 0 window situation? A well behaving sctp peer may not, > but we're on the Internet, everyone behaves at their worst :-) > > Seriously, this would make for a simple dos. Establish a stream, don't ack any > data to make sure there is something on the retransmission queue of the peer. > Immediately shutdown the stream and ack any retransmission attempt with > a_rwnd=0 to keep the association around forever. > > Starting the T5 SHUTDOWN GUARD timer is specified as MAY and not MUST so even in > a well behaving world we could not really rely on it. > > Alternatively the peer could just be buggy as well. > You are right. Without a receiver patch, a linux receiver would stay in 0-window condition while sending a SHUTDOWN with a_rwnd of 0. How about instead of checking for "Not greater then or equals", we instead simply test for "less then"? -vlad