<div dir="ltr">Good day,<div><br></div><div>Our environment:</div><div>Erlang 17.5 64bit - Centos</div><div><br></div><div>We've implemented sctp client using gen_sctp and associations comes up fine and closes fine. A main process opens a gen_sctp port and connect outgoing associations. Each established association is peeled off and control is handed over to a spawned process. If the spawned process is shutdown orderly and closes its socket, the association is cleaned up properly. The same association (same local IP/port same remote IP port) can be re-established via the main process (connect, peeloff and then control is passed to spawned process)  </div><div><br></div><div>Under certain conditions, the spawned process would terminate and close its socket, but the association is not cleaned up entirely. Instead control of the association is handed back to the main process (can see events for the association being received by the main process). Attempt would be made to connect but comes back with ealready (operation in process) or eisconn (socket is already connected). On OS, the sctp association be seen in CLOSE state. It is only when the main process closes the original port is when the 'child socket' is released.</div><div><br></div><div>We've managed to simulating this by pulling the lan cable out on the client side and the association lands up in CLOSE state. Once the cable is plugged in again, the association events for that association ID  are received by the main process.</div><div><br></div><div>These are the following questions I have:</div><div>1. When closing the peeloff socket, does that not cleanup the underlying socket and its association?</div><div><br></div><div>2. Is this intended behaviour?</div><div><br></div><div>Any response would be appreciated. Thanks</div><div><br></div><div>Regards,</div><div>Steven</div><div><br></div></div>