From: Daniel Borkmann <dborkman@redhat.com>
To: Sun Paul <paulrbk@gmail.com>
Cc: linux-sctp@vger.kernel.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, vyasevich@gmail.com
Subject: Re: Fwd: Question on SCTP ABORT chunk is generated when the association_max_retrans is reached
Date: Fri, 23 Jan 2015 11:50:25 +0000 [thread overview]
Message-ID: <54C23581.9060809@redhat.com> (raw)
In-Reply-To: <CAFXGft+fwo=8LJEG7h6uOpGciSo5f_dXjSx3sn67RZZp7jsYHw@mail.gmail.com>
Hi,
On 01/23/2015 11:25 AM, Sun Paul wrote:
...
> I would like to check the behave in LKSCTP.
>
> we are running DIAMETER message over SCTP, and we have set the
> parameter "net.sctp.association_max_retrans = 4" in the LinuxOS.
>
> We noticed that when remote peer have retry to send the same request
> for 4 times, the LKSCTP will initiate an ABORT chunk with reason
> "association exceeded its max_retrans count".
>
> We would like to know whether this is the correct behavior? is there
> any other option that we can alter in order to avoid the ABORT chunk
> being sent?
I don't recall the RFC saying to send an ABORT, but let me double
check in the mean time.
Hmm, untested, but could you try something like that?
diff --git a/net/sctp/sm_sideeffect.c b/net/sctp/sm_sideeffect.c
index fef2acd..5ce198d 100644
--- a/net/sctp/sm_sideeffect.c
+++ b/net/sctp/sm_sideeffect.c
@@ -584,7 +584,8 @@ static void sctp_cmd_assoc_failed(sctp_cmd_seq_t *commands,
sctp_add_cmd_sf(commands, SCTP_CMD_EVENT_ULP,
SCTP_ULPEVENT(event));
- if (asoc->overall_error_count >= asoc->max_retrans) {
+ if (asoc->overall_error_count >= asoc->max_retrans &&
+ error != SCTP_ERROR_NO_ERROR) {
abort = sctp_make_violation_max_retrans(asoc, chunk);
if (abort)
sctp_add_cmd_sf(commands, SCTP_CMD_REPLY,
WARNING: multiple messages have this Message-ID (diff)
From: Daniel Borkmann <dborkman@redhat.com>
To: Sun Paul <paulrbk@gmail.com>
Cc: linux-sctp@vger.kernel.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, vyasevich@gmail.com
Subject: Re: Fwd: Question on SCTP ABORT chunk is generated when the association_max_retrans is reached
Date: Fri, 23 Jan 2015 12:50:25 +0100 [thread overview]
Message-ID: <54C23581.9060809@redhat.com> (raw)
In-Reply-To: <CAFXGft+fwo=8LJEG7h6uOpGciSo5f_dXjSx3sn67RZZp7jsYHw@mail.gmail.com>
Hi,
On 01/23/2015 11:25 AM, Sun Paul wrote:
...
> I would like to check the behave in LKSCTP.
>
> we are running DIAMETER message over SCTP, and we have set the
> parameter "net.sctp.association_max_retrans = 4" in the LinuxOS.
>
> We noticed that when remote peer have retry to send the same request
> for 4 times, the LKSCTP will initiate an ABORT chunk with reason
> "association exceeded its max_retrans count".
>
> We would like to know whether this is the correct behavior? is there
> any other option that we can alter in order to avoid the ABORT chunk
> being sent?
I don't recall the RFC saying to send an ABORT, but let me double
check in the mean time.
Hmm, untested, but could you try something like that?
diff --git a/net/sctp/sm_sideeffect.c b/net/sctp/sm_sideeffect.c
index fef2acd..5ce198d 100644
--- a/net/sctp/sm_sideeffect.c
+++ b/net/sctp/sm_sideeffect.c
@@ -584,7 +584,8 @@ static void sctp_cmd_assoc_failed(sctp_cmd_seq_t *commands,
sctp_add_cmd_sf(commands, SCTP_CMD_EVENT_ULP,
SCTP_ULPEVENT(event));
- if (asoc->overall_error_count >= asoc->max_retrans) {
+ if (asoc->overall_error_count >= asoc->max_retrans &&
+ error != SCTP_ERROR_NO_ERROR) {
abort = sctp_make_violation_max_retrans(asoc, chunk);
if (abort)
sctp_add_cmd_sf(commands, SCTP_CMD_REPLY,
next prev parent reply other threads:[~2015-01-23 11:50 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-01-23 10:09 Question on SCTP ABORT chunk is generated when the association_max_retrans is reached Sun Paul
2015-01-23 10:25 ` Fwd: " Sun Paul
2015-01-23 10:25 ` Sun Paul
2015-01-23 11:50 ` Daniel Borkmann [this message]
2015-01-23 11:50 ` Daniel Borkmann
2015-01-23 16:05 ` Vlad Yasevich
2015-01-23 16:05 ` Vlad Yasevich
2015-01-23 17:10 ` Daniel Borkmann
2015-01-23 17:10 ` Daniel Borkmann
2015-01-23 18:30 ` Vlad Yasevich
2015-01-23 18:30 ` Vlad Yasevich
2015-01-23 18:36 ` Michael Tuexen
2015-01-23 18:36 ` Michael Tuexen
2015-01-26 13:47 ` Fwd: " Neil Horman
2015-01-26 13:47 ` Neil Horman
2015-01-23 18:36 ` Michael Tuexen
2015-01-23 18:36 ` Michael Tuexen
2015-01-23 19:05 ` Daniel Borkmann
2015-01-23 19:05 ` Daniel Borkmann
2015-01-26 1:27 ` Sun Paul
2015-01-26 1:27 ` Sun Paul
2015-01-26 11:46 ` Marcelo Ricardo Leitner
2015-01-26 11:46 ` Marcelo Ricardo Leitner
2015-01-26 13:17 ` Sun Paul
2015-01-26 13:17 ` Sun Paul
2015-01-26 13:30 ` Daniel Borkmann
2015-01-26 13:30 ` Daniel Borkmann
2015-01-23 16:08 ` Fwd: " Vlad Yasevich
2015-01-23 16:08 ` Vlad Yasevich
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=54C23581.9060809@redhat.com \
--to=dborkman@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-sctp@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=paulrbk@gmail.com \
--cc=vyasevich@gmail.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.