[sctp-dev] Strange closing of SCTP channel

[Chris Hegarty]

On 11/15/11 09:54 AM, Jens Carlberg wrote:
> 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... :-)

Hmm... interesting.

> * 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.

You can use SctpChannel.bind/bindAddress/unbindAddress

> * 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?

I'm afraid I can't answer these questions. The Java SCTP implementation 
is a wrapper on top of the Linux Kernel SCTP implementation. These 
issues sound more likely to be kernel issues rather that anything in Java.

Have you tried with lksctp-developers at lists.sourceforge.net?? These guys 
are responsible for the lksctp stack in the Linux kernel and are really 
helpful.

-Chris.

>
>
> ///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>
>>