linux-sctp.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Franklin Marmon" <marmon@hydeco.com>
To: linux-sctp@vger.kernel.org
Subject: RE: address already in use on previously used (but currently unused) IP:PORT combinations in sctp_bi
Date: Wed, 02 Aug 2017 14:08:12 +0000	[thread overview]
Message-ID: <044b01d30b98$ca457340$5ed059c0$@hydeco.com> (raw)
In-Reply-To: <0bbe01d30afe$80ce96f0$826bc4d0$@hydeco.com>

In this case I waited over 20 hours. If the connections were in a "time
wait" state I would have expected to see them listed somewere, similar to a
TCP socket in time wait, or is that not the case with sctp? Additionally,
the sctp kernel driver showed 6 uses. There were 5 total "real" uses, killed
all applications on the system using sctp, the module still showed 1 use.
Force removed the kernel module and reloaded it and the binds were
successful. My suspicion is that the 6th use was a state entry in the sctp
module that was somehow holding the ports as being in use but I'm not sure
how to tell.

frm

Franklin Marmon
The Hyde Company
331 East Broadway
Missoula, MT 59801

Office: 406.541.4777
Cell: 406.493.2460
http://www.hydeco.com
marmon@hydeco.com

-----Original Message-----
From: David Laight [mailto:David.Laight@ACULAB.COM] 
Sent: Wednesday, August 2, 2017 3:09 AM
To: 'marmon@hydeco.com' <marmon@hydeco.com>; linux-sctp@vger.kernel.org
Cc: smcclain@hydeco.com; jerry@hydeco.com
Subject: RE: address already in use on previously used (but currently
unused) IP:PORT combinations in sctp_bindx()

From: Franklin Marmon
> Sent: 01 August 2017 20:44
> I'm having trouble with sctp_bindx() reporting address already in use 
> when attempting to bind sockets. The IP:PORT combinations are not 
> open, do not show up in /proc/net/sctp/assocs, netstat, ss, or lsof. 
> The IP:PORTs were bound in a previous instance of the client 
> application however that application itself has been killed and 
> restarted. It is as if the kernel believes the IP:PORT pair is in use 
> when, as far as I can tell, it isn't. If I change the ports used in my 
> addresses to ports I have not used previously the bind succeeds 
> without issue. Any suggestions on how I can tell what is holding the ports
open, or how to reset the sctp port table in the kernel?

How long are you waiting?
Possibly the old connections are in some 'time wait' state.

I've always found it necessary to specify SO_REUSADDR to make anything
restartable (although that may not help here).

	David




  parent reply	other threads:[~2017-08-02 14:08 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-08-01 19:43 address already in use on previously used (but currently unused) IP:PORT combinations in sctp_bindx( Franklin Marmon
2017-08-02  9:08 ` address already in use on previously used (but currently unused) IP:PORT combinations in sctp_bi David Laight
2017-08-02 13:28 ` Xin Long
2017-08-02 14:08 ` Franklin Marmon [this message]
2017-08-02 14:09 ` Franklin Marmon
2017-08-03  0:37 ` Xin Long
2017-11-20 16:29 ` Franklin Marmon

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='044b01d30b98$ca457340$5ed059c0$@hydeco.com' \
    --to=marmon@hydeco.com \
    --cc=linux-sctp@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).