SCTP Discussions

Text archives Help


Re: [SCTP-Discussion] ch_enterPRSCTPfromInit infinite loop.


Chronological Thread 
  • From: Thomas Dreibholz <dreibh AT iem.uni-due.de>
  • To: Nils Olav Selåsdal - Utel Systems <nos AT utel.no>, "sctp-discussion AT sctp.de" <sctp-discussion AT sctp.de>
  • Subject: Re: [SCTP-Discussion] ch_enterPRSCTPfromInit infinite loop.
  • Date: Wed, 08 Aug 2012 21:09:37 +0200
  • List-archive: <http://lists.franken.de/pipermail/sctp-discussion>
  • List-id: SCTP Discussions <sctp-discussion.sctp.de>
  • Organization: University of Duisburg-Essen, Institute for Experimental Mathematics

Dear Nils,

you can also try our latest sctplib from the Git repository at
https://github.com/dreibh/sctplib.git . It contains some updates that will be
included in the next release of sctplib.

Onsdag 09 mai 2012 10:40:09 skrev du:
> > -----Original Message-----
> > From: Thomas Dreibholz
> > [mailto:dreibh AT iem.uni-due.de]
> > Sent: Wednesday, 09 May, 2012 09:36
> > To:
> > sctp-discussion AT sctp.de
> > Cc: Michael Tuexen; Nils Olav Selåsdal - Utel Systems;
> > discussion AT sctp.de
> > Subject: Re: [SCTP-Discussion] ch_enterPRSCTPfromInit infinite loop.
> >
> > Am Freitag 27 April 2012, 15:25:07 schrieb Michael Tuexen:
> >
> > > On Apr 27, 2012, at 1:10 PM, Nils Olav Selåsdal - Utel Systems wrote:
> > >
> > > > Hi,
> > > > We got into an infinite loop just now, ch_enterPRSCTPfromInit() got
> > > > stuck with pLen being 0 in this loop,
> > > >
> > > >
> > > >
> > > > while (curs < vlp_totalLength) {
> > > >
> > > >
> > > >
> > > > ack_string = &((SCTP_init
> > > > *)chunks[initAckCID])->variableParams[writeCursor[initAckCID]];
> > > >
> > > > vl_initPtr = (SCTP_vlparam_header *) & init_string[curs];
> > > > pType = ntohs(vl_initPtr->param_type);
> > > > pLen = ntohs(vl_initPtr->param_length);
> > > >
> > > >
> > > >
> > > > if (pLen < 4) result = -1; /* peer error - ignore - should send
> > > > an
> > > > error notification */
> > > >
> > > >
> > > >
> > > > event_logiii(VERBOSE, "Scan variable parameters: Got type %u,
> > > > len:
> > > > %u, position %u",pType, pLen, curs);
> > > >
> > > >
> > > >
> > > > if (pType == VLPARAM_PRSCTP) {
> > > >
> > > >
> > > >
> > > > /* ha, we got one ! */
> > > >
> > > >
> > > >
> > > > if (pLen == 4) result = 0; /* peer supports it, but
> > > > doesn't
> > > > send anything unreliably */ if (pLen > 4) result = 1; /*
> > > > peer supports it, and does send some */ memcpy(ack_string,
> > > > vl_initPtr, pLen);
> > > > writeCursor[initAckCID] += pLen;
> > > >
> > > >
> > > >
> > > > }
> > > > curs += pLen;
> > > > while ((curs % 4) != 0) curs++;
> > > >
> > > >
> > > >
> > > > }
> > > >
> > > >
> > > >
> > > > I’d assume it’ll be safe to change if (pLen < 4) result = -1; to
> > > > if(pLen < 4) return -1; here ?
> > >
> > > That seems correct. However, checking for pLen > 4 seems suspicious. I
> > > guess the sctplib implements some draft version, not PR-SCTP as
> > > specified in RFC 3758.
> >
> >
> > Did you any updates and testing of the change?
> >
> > If it is working, please send us a patch. Then, we can include it in the
> > next release of sctplib.
>
>
> Hi,
> I just did the change in the attached patch, which at least prevents sctplib
> from entering an infinite loop on replying to a malformed INIT, though
> it's not a real fix as it also results in sending a malformed init_ack
> back.

--
Best regards / Mit freundlichen Grüßen / Med vennlig hilsen

====================================================================== Thomas
Dreibholz

Simula Research Laboratory
Simula Innovation AS, Network Systems Group
Visiting address: Martin Linges vei 17, 1364 Fornebu, Norway
Mailing address: P.O.Box 134, 1325 Lysaker, Norway
-----------------------------------------------------------------------
E-Mail:
dreibh AT simula.no
Homepage: http://simula.no/people/dreibh
=====================================================================

Attachment: signature.asc
Description: This is a digitally signed message part.



  • Re: [SCTP-Discussion] ch_enterPRSCTPfromInit infinite loop., Thomas Dreibholz, 08/08/2012

Archive powered by MHonArc 2.6.19+.

Top of page