[sctp-dev] Strange closing of SCTP channel

[Jens Carlberg]

Chris,

We have managed to narrow down the problem to the fact that the INIT message contains 2 IP addresses for the client. When shutting down the extra interface, the problem went away. This, of course, triggers new questions... :-)

* How can we control what IP addresses the SCTP will send in the INIT message? For our current testing we can shutdown the interface, but it is not a solution in the long run.
* The two machines have the same IP address on an interface; will this trigger the behaviour we have seen?
* We see the COMM_LOST after between 2 and 5 seconds. How come we see such different times?


///Best regards, Jens Carlberg

-----Original Message-----
From: Chris Hegarty [mailto:chris.hegarty at oracle.com] 
Sent: den 14 november 2011 15:37
To: Jens Carlberg
Cc: sctp-dev at openjdk.java.net
Subject: Re: [sctp-dev] Strange closing of SCTP channel

Jens,

Sorry, I haven't seen this strange type of behavior before. Is it possible for you to test the client with the SCTP implementation from
JDK7 in case this is some strange issue with taking the implementation out of 7 and putting it in 6?

-Chris.

On 10/11/2011 14:02, Jens Carlberg wrote:
> Hi!
> I and a colleague are working with an application, working as SCTP 
> server. We're seeing a strange behaviour we fail to understand, where 
> the SCTP link closes on the server side when we are using a test 
> client, without any reason we can perceive. When used with a "real" 
> client, the link has no such problems. Also, the test client works 
> well when used over the loopback interface.
> The sequence looks like this:
> * The server starts and accepts incoming connections.
> * The client starts and connects, getting a SCTP channel. We have 
> dumped the network traffic and can see the complete startup sequence 
> from INIT to COOKIE_ACK.
> * The client sends a request (a telecom protocol using SCTP as 
> transport). The server sends a response. After this the link should 
> stay open, waiting for further communication.
> * After a second or two, we can see in our application that SCTP 
> delivers a notification, a AssociationChangeNotification with COMM_LOST.
> There is no packet corresponding to this in the network traffic dump 
> we have looked at.
> * After about 30 seconds, the client sends a HEARTBEAT and gets an 
> ABORT back.
> When using a "real" client or loopback interface, there is no 
> notification delivered and the link stays up. We have gotten a network 
> dump for the "real" client case, but not for the loopback interface.
> We are using...
> * Java 1.6.18 with the SCTP from Java 7.
> * Linux 2.6.32.12 with a hight refresh rate (1000 Hz instead of 250)
> * lksctp-tools-1.0.10-2.1 and lksctp-tools-devel-1.0.10-2.1 Under what 
> circumstances will a notification be generated? Can there be traffic 
> we doesn't see, since we only look for traffic to/from the client? Can 
> there be notification generated by other events?
> We include the two network dumps we have collected.
>
> ///Best regards,
>
> line
>
> *JENS CARLBERG **
> Software Designer*
>
>
> Ericsson AB
> FU Radio System I&V, LI/EAB/FJZ/TE
> Datalinjen 4
> SE-58112 Linköping, Sweden
> Phone +46 107114141
> SMS/MMS +46 761497941
> jens.carlberg at ericsson.com
> www.ericsson.com
>
>
>
> Ericsson
>
>
>
>
> This Communication is Confidential. We only send and receive email on 
> the basis of the terms set out at www.ericsson.com/email_disclaimer 
> <http://www.ericsson.com/email_disclaimer>
>