Re: SCTP Abort

On Feb 26, 2009, at 5:07 PM, Ashish_Soregaonkar wrote:

> Oh yes. My bad. I should have said maintenance message ASPUP.
>
> You can look at the difference between packet 2 & 8 and similarity  
> between 8 & 11.
> 2- ASPUP - stream 1 - Abort
It is stream 0, stream sequence number 1.
I guess this is an M3UA level retransmission...
>
> 8- ASPUP - stream 0 - no abort
It is stream 0, stream sequence number 0.
>
> 11 - ASPAC - stream 1 - abort
It is stream 0, stream sequence number 1.

At least this is what Wireshark tells me...
>
>
> Thanks,
> _Ashish
>
> -----Original Message-----
> From: Michael Tüxen [mailto:[email protected]]
> Sent: Thursday, February 26, 2009 9:29 PM
> To: Ashish_Soregaonkar
> Cc: [email protected]
> Subject: Re: [Sigtran] SCTP Abort
>
> Hi Ashish,
>
> I do not see any management messages sent on stream 1...
>
> The SCTP implementations are pretty outdated... The one
> of the softswitch includes a single IP address in the
> INIT chunk and it uses the Adler checksum. Not sure whether
> the SCTP stack of the SG just adopts to it.
>
> I'm not sure how good the SCTP stack of the SG is, but
> the T-bit is set in all ABORTs. If the stack is correct,
> it means that it has no state about the association.
>
> This would mean that it responds to an ASPUP with an
> ASPUP-ACK and removes the state at the M3UA and SCTP
> layer without notifying the peer. The ABORTs are in
> response to incoming packets when the state is already
> gone.
>
> Best regards
> Michael
>
> On Feb 26, 2009, at 4:34 PM, Ashish_Soregaonkar wrote:
>
>>
>> Arvind,
>>
>> Have you noticed that the SG is aborting the association in response
>> to management messages sent on stream 1. While for similar
>> management messages on stream 0 it replies with the expected
>> response. Though M3UA Error is expected here as per RFC 4333 & 3332.
>>
>> I agree with Brian. It would be better to check the conformance of
>> you SCTP implementation.
>>
>> HTH,
>> _Ashish
>>
>> -----Original Message-----
>> From: [email protected] [mailto:[email protected]] On
>> Behalf Of Brian F. G. Bidulock
>> Sent: Thursday, February 26, 2009 8:50 PM
>> To: Arvind Kumar
>> Cc: [email protected]
>> Subject: Re: [Sigtran] SCTP Abort
>>
>> Arvind,
>>
>> Your log file shows both implementations using
>> Adler32 checksum.  The checksum was updated to
>> CRC32c some years ago, why is it using Adler32?
>>
>> That is: a conforming SCTP configuration might
>> be a better place to start...
>>
>> --brian
>>
>> Arvind Kumar wrote:                          (Thu, 26 Feb 2009
>> 14:09:46)
>>>
>>>  Hello Sigtran Gurus!
>>>  I am bringing Signaling Gateway Stack with Softswitch as follows:
>>>             Signaling Gateway -------------          Softswitch
>>>             192.168.103.160
>>>  192.168.103.170
>>>      Association is established then goes down, softswitch
>>> establishes
>>>  the association (four way handshake), it brings up the association,
>>>  but suddenly Signaling Gateway is aborting the association by
>>> sending
>>>  SCTP ABORT. This is happening again and again.
>>>  Surprising thing is that there is no reason in  ABORT msg.
>>>  Could you please give me any clue regarding this.
>>>  I have attached the log.
>>>  Thanks & Regards,
>>>  Arvind
>>
>>
>>> _______________________________________________
>>> Sigtran mailing list
>>> [email protected]
>>> https://www.ietf.org/mailman/listinfo/sigtran
>>
>>
>> -- 
>> Brian F. G. Bidulock
>> [email protected]
>> http://www.openss7.org/
>> _______________________________________________
>> Sigtran mailing list
>> [email protected]
>> https://www.ietf.org/mailman/listinfo/sigtran
>>
>> **************** CAUTION - Disclaimer *****************
>> This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION
>> intended solely
>> for the use of the addressee(s). If you are not the intended
>> recipient, please
>> notify the sender by e-mail and delete the original message.
>> Further, you are not
>> to copy, disclose, or distribute this e-mail or its contents to any
>> other person and
>> any such actions are unlawful. This e-mail may contain viruses.
>> Infosys has taken
>> every reasonable precaution to minimize this risk, but is not liable
>> for any damage
>> you may sustain as a result of any virus in this e-mail. You should
>> carry out your
>> own virus checks before opening the e-mail or attachment. Infosys
>> reserves the
>> right to monitor and review the content of all messages sent to or
>> from this e-mail
>> address. Messages sent to or from this e-mail address may be stored
>> on the
>> Infosys e-mail system.
>> ***INFOSYS******** End of Disclaimer ********INFOSYS***
>> _______________________________________________
>> Sigtran mailing list
>> [email protected]
>> https://www.ietf.org/mailman/listinfo/sigtran
>>
>
>