linux-kernel - RE: Address already in use problem

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <063D6719AE5E284EB5DD2968C1650D6DB010623F@AcuExch.aculab.com>
Date:   Wed, 21 Sep 2016 15:56:41 +0000
From:   David Laight <David.Laight@...LAB.COM>
To:     'Neil Horman' <nhorman@...driver.com>, Sun Paul <paulrbk@...il.com>
CC:     "linux-sctp@...r.kernel.org" <linux-sctp@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: Address already in use problem

From: Neil Horman
> Sent: 21 September 2016 16:43
> On Wed, Sep 21, 2016 at 09:44:30PM +0800, Sun Paul wrote:
> > Hi
> >
> > we have an SCTP application running in JAVA. and we found that there
> > is a problem when we as a client trying to connect to a remote IP
> > address.
> >
> > If the remote IP address is not accessible, our application will keep
> > retrying to connect using a self-defined local port address, says
> > 51001,
> >
> > We found that after sometimes, says 2 hrs, this port 51001 is never
> > able to bind to us again. even we tried to restart the application.
> >
> Sounds like you have another application that inadvertently bound to that port.
> Its not a privlidged port, nor is it well known, so it seems plausible that
> another application would eventually bind to it.  Thats not a bug, just the way
> ip works.
> 
> run netstat -anp | grep 51001
> 
> And see what application is holding the port.

Not much chance of a distro having a netstat that gives sctp info.
You might find something in /proc/net/sctp.

3.18 contains a fix for a problem with shutdown() being called
after the remote sends an INIT to restart an active connection
when there is unacked data.
If that happens the socket isn't released ever.

A workaround is to use SO_LINGER to get the connection aborted.

	David