linux-sctp.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andreas Fink <afink@list.fink.org>
To: linux-sctp@vger.kernel.org
Subject: Re: Heartbeat on closed SCTP sockets?
Date: Tue, 06 Oct 2020 13:31:49 +0000	[thread overview]
Message-ID: <920ED78B-0CDF-43A0-B3FB-42D25E249BD4@list.fink.org> (raw)
In-Reply-To: <1FB70B30-857C-4CD9-A05C-4BA15F57B1D2@list.fink.org>

here are the matching entries:

ss -a --sctp
State                        Recv-Q                      Send-Q                                                         Local Address:Port                                                            Peer Address:Port
LISTEN                       0                           128                                                   [::ffff:194.0.137.189]:2020                                                                       *:*
UNCONN                       0                           0                                                     [::ffff:194.0.137.189]:2020                                                                       *:1202
SYN-RECV                     0                           0                                                [::ffff:194.0.137.234]%eth0:2020                                                                       *:1202

from /proc/net/sctp/assocs

 ASSOC     SOCK   STY SST ST HBKT ASSOC-ID TX_QUEUE RX_QUEUE UID INODE LPORT RPORT LADDRS <-> RADDRS HBINT INS OUTS MAXRT T1X T2X RTXC wmema wmemq sndbuf rcvbuf
6947dc99 7e08fe9b 1   7   3  0       5        0        0       0     0 2020   1202  194.0.137.234 194.0.137.189 <-> *93.95.48.82 93.95.48.90        7500     2    10   10    0    2        9        1        0   212992   212992

The application opens up a IPv6 socket with IPv4 conversion.
It opens a listener socket on 2020 and had a connection with the indicated IPs (its multihomed with two IPs).
The entry in /proc/net/sctp/assocs refers to the association which is being kept alive by the remote
but in ss -a --sctp you can see its "unconnected" and listening. So the connection above should be handed over to the listener port and a SCTP UP message should be delivered to the application upon which my application would call sctp_peeloff and everything would restart.


quite confusing.


> On 5 Oct 2020, at 19:16, Marcelo Ricardo Leitner <marcelo.leitner@gmail.com> wrote:
> 
> Hi,
> 
> On Mon, Oct 05, 2020 at 06:39:22PM +0200, Andreas Fink wrote:
> ...
>> What we now see in netstat --sctp is:
>> 
>> we have a LISTEN on port 2010
>> we have a  association from port 2010 to the remote in status CLOSED
>> 
>> in tcpdump we see packets coming in from the remote and heartbeat being acknowledged. However our application is not answering to these packets and the status of the application shows SCTP being down.
>> In other words, my application sees the association down. Netstat shows the association as being closed but the kernel seems to continue to entertain this association by continue to send heartbeat ACK and not sending ABORT.
> 
> That's weird. If it is in CLOSED, then the stack should be handling
> it as an OOTB packet and trigger an Abort.
> 
>> 
>> We now kill the application
>> 
>> What we now see in netstat --sctp is:
>> we no longer listen on port 2010
>> we have a closed association from port 2010 to the remote.
>> 
>> in tcpdump we however we STILL see packets coming in from the remote and heartbeat being acknowledged, even though no application is listening on this port and no userspace application is using that port.
>> We do not see any SHUTDOWN or INIT even if we restart the application.
>> 
>> Can anyone explain how this can be?
> 
> Please check the assoc status as well, via 'ss -a --sctp' and
> /proc/net/sctp/assocs . Maybe it got out of sync of the socket status.
> 
>  Marcelo

WARNING: multiple messages have this Message-ID (diff)
From: Andreas Fink <afink@list.fink.org>
To: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
Cc: linux-sctp@vger.kernel.org
Subject: Re: Heartbeat on closed SCTP sockets?
Date: Tue, 6 Oct 2020 15:31:49 +0200	[thread overview]
Message-ID: <920ED78B-0CDF-43A0-B3FB-42D25E249BD4@list.fink.org> (raw)
Message-ID: <20201006133149.L5--qQQsZBY0Y0oPjNQVIoYbNh5DdxhZmqbEgDl-_v0@z> (raw)
In-Reply-To: <20201005171643.GK70998@localhost.localdomain>

here are the matching entries:

ss -a --sctp
State                        Recv-Q                      Send-Q                                                         Local Address:Port                                                            Peer Address:Port
LISTEN                       0                           128                                                   [::ffff:194.0.137.189]:2020                                                                       *:*
UNCONN                       0                           0                                                     [::ffff:194.0.137.189]:2020                                                                       *:1202
SYN-RECV                     0                           0                                                [::ffff:194.0.137.234]%eth0:2020                                                                       *:1202

from /proc/net/sctp/assocs

 ASSOC     SOCK   STY SST ST HBKT ASSOC-ID TX_QUEUE RX_QUEUE UID INODE LPORT RPORT LADDRS <-> RADDRS HBINT INS OUTS MAXRT T1X T2X RTXC wmema wmemq sndbuf rcvbuf
6947dc99 7e08fe9b 1   7   3  0       5        0        0       0     0 2020   1202  194.0.137.234 194.0.137.189 <-> *93.95.48.82 93.95.48.90        7500     2    10   10    0    2        9        1        0   212992   212992

The application opens up a IPv6 socket with IPv4 conversion.
It opens a listener socket on 2020 and had a connection with the indicated IPs (its multihomed with two IPs).
The entry in /proc/net/sctp/assocs refers to the association which is being kept alive by the remote
but in ss -a --sctp you can see its "unconnected" and listening. So the connection above should be handed over to the listener port and a SCTP UP message should be delivered to the application upon which my application would call sctp_peeloff and everything would restart.


quite confusing.


> On 5 Oct 2020, at 19:16, Marcelo Ricardo Leitner <marcelo.leitner@gmail.com> wrote:
> 
> Hi,
> 
> On Mon, Oct 05, 2020 at 06:39:22PM +0200, Andreas Fink wrote:
> ...
>> What we now see in netstat --sctp is:
>> 
>> we have a LISTEN on port 2010
>> we have a  association from port 2010 to the remote in status CLOSED
>> 
>> in tcpdump we see packets coming in from the remote and heartbeat being acknowledged. However our application is not answering to these packets and the status of the application shows SCTP being down.
>> In other words, my application sees the association down. Netstat shows the association as being closed but the kernel seems to continue to entertain this association by continue to send heartbeat ACK and not sending ABORT.
> 
> That's weird. If it is in CLOSED, then the stack should be handling
> it as an OOTB packet and trigger an Abort.
> 
>> 
>> We now kill the application
>> 
>> What we now see in netstat --sctp is:
>> we no longer listen on port 2010
>> we have a closed association from port 2010 to the remote.
>> 
>> in tcpdump we however we STILL see packets coming in from the remote and heartbeat being acknowledged, even though no application is listening on this port and no userspace application is using that port.
>> We do not see any SHUTDOWN or INIT even if we restart the application.
>> 
>> Can anyone explain how this can be?
> 
> Please check the assoc status as well, via 'ss -a --sctp' and
> /proc/net/sctp/assocs . Maybe it got out of sync of the socket status.
> 
>  Marcelo



  parent reply	other threads:[~2020-10-06 13:31 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-05 16:39 Heartbeat on closed SCTP sockets? Andreas Fink
2020-10-05 16:39 ` Andreas Fink
2020-10-05 17:16 ` Marcelo Ricardo Leitner
2020-10-05 17:16   ` Marcelo Ricardo Leitner
2020-10-06 13:31 ` Andreas Fink [this message]
2020-10-06 13:31   ` Andreas Fink
2020-10-08  6:40 ` Andreas Fink
2020-10-08  6:40   ` Andreas Fink
2020-10-08  8:13 ` David Laight
2020-10-08  8:13   ` David Laight
2020-10-08  9:08 ` Michael Tuexen
2020-10-08  9:08   ` Michael Tuexen
2020-10-08 10:57 ` Andreas Fink
2020-10-08 10:57   ` Andreas Fink
2020-10-08 11:02 ` Andreas Fink
2020-10-08 11:02   ` Andreas Fink

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=920ED78B-0CDF-43A0-B3FB-42D25E249BD4@list.fink.org \
    --to=afink@list.fink.org \
    --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).