From: Michael Tuexen <tuexen@fh-muenster.de> To: Vlad Yasevich <vyasevich@gmail.com> Cc: Daniel Borkmann <dborkman@redhat.com>, Sun Paul <paulrbk@gmail.com>, linux-sctp@vger.kernel.org, netdev@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: Question on SCTP ABORT chunk is generated when the association_max_retrans is reached Date: Fri, 23 Jan 2015 19:36:38 +0100 [thread overview] Message-ID: <628C9A19-FFC7-4D98-9FBB-D59F45BF6915@fh-muenster.de> (raw) In-Reply-To: <54C2935F.2000105@gmail.com> > On 23 Jan 2015, at 19:30, Vlad Yasevich <vyasevich@gmail.com> wrote: > > On 01/23/2015 12:10 PM, Daniel Borkmann wrote: >> On 01/23/2015 05:05 PM, Vlad Yasevich wrote: >>> On 01/23/2015 06:50 AM, Daniel Borkmann wrote: >>>> 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. >>> >>> The RFC is silent on the matter. The abort got added in 3.8 so >>> it's been there for a while. >> >> I see, commit de4594a51c90 ("sctp: send abort chunk when max_retrans >> exceeded") added the behaviour. >> >>>> 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, >>> >>> This would pretty much stop all ABORTs due to excessive rtx. Might >>> as well take the code out :). >>> >>> I was a bit concerned about this ABORT when it went in. >> >> So effectively, if I understand the argument from the commit, the >> assumption is that the ABORT would never reach the peer anyway, but >> is a way for tcpdump users to see on the wire that rtx limit has >> been exceeded and since there's not mentioned anything in the RFC >> about this, it doesn't break it. Hm. >> > > Additionally I seem to recall BSD sending this type of ABORT for pretty > much the same reason. Yepp. Best regards Michael > > -vlad > >> Sun Paul, what exactly broke in your scenario? Can you be more explicit? >> >> Thanks, >> Daniel > >
WARNING: multiple messages have this Message-ID (diff)
From: Michael Tuexen <tuexen@fh-muenster.de> To: Vlad Yasevich <vyasevich@gmail.com> Cc: Daniel Borkmann <dborkman@redhat.com>, Sun Paul <paulrbk@gmail.com>, linux-sctp@vger.kernel.org, netdev@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: Question on SCTP ABORT chunk is generated when the association_max_retrans is reached Date: Fri, 23 Jan 2015 18:36:38 +0000 [thread overview] Message-ID: <628C9A19-FFC7-4D98-9FBB-D59F45BF6915@fh-muenster.de> (raw) In-Reply-To: <54C2935F.2000105@gmail.com> > On 23 Jan 2015, at 19:30, Vlad Yasevich <vyasevich@gmail.com> wrote: > > On 01/23/2015 12:10 PM, Daniel Borkmann wrote: >> On 01/23/2015 05:05 PM, Vlad Yasevich wrote: >>> On 01/23/2015 06:50 AM, Daniel Borkmann wrote: >>>> 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. >>> >>> The RFC is silent on the matter. The abort got added in 3.8 so >>> it's been there for a while. >> >> I see, commit de4594a51c90 ("sctp: send abort chunk when max_retrans >> exceeded") added the behaviour. >> >>>> 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, >>> >>> This would pretty much stop all ABORTs due to excessive rtx. Might >>> as well take the code out :). >>> >>> I was a bit concerned about this ABORT when it went in. >> >> So effectively, if I understand the argument from the commit, the >> assumption is that the ABORT would never reach the peer anyway, but >> is a way for tcpdump users to see on the wire that rtx limit has >> been exceeded and since there's not mentioned anything in the RFC >> about this, it doesn't break it. Hm. >> > > Additionally I seem to recall BSD sending this type of ABORT for pretty > much the same reason. Yepp. Best regards Michael > > -vlad > >> Sun Paul, what exactly broke in your scenario? Can you be more explicit? >> >> Thanks, >> Daniel > >
next prev parent reply other threads:[~2015-01-23 19:07 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 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 [this message] 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=628C9A19-FFC7-4D98-9FBB-D59F45BF6915@fh-muenster.de \ --to=tuexen@fh-muenster.de \ --cc=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: linkBe 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.