Re: SCTP Abort

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
8- ASPUP - stream 0 - no abort
11 - ASPAC - stream 1 - abort

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
>