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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ