public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: xufeng zhang <xufeng.zhang@windriver.com>
To: Neil Horman <nhorman@tuxdriver.com>
Cc: <xufengzhang.main@gmail.com>, <vyasevich@gmail.com>,
	<sri@us.ibm.com>, <davem@davemloft.net>,
	<linux-sctp@vger.kernel.org>, <netdev@vger.kernel.org>,
	<linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] sctp: Make "Invalid Stream Identifier" ERROR follows SACK when bundling
Date: Mon, 23 Jul 2012 10:30:34 +0800	[thread overview]
Message-ID: <500CB74A.4040300@windriver.com> (raw)
In-Reply-To: <20120723004932.GB8040@neilslaptop.think-freely.org>

On 07/23/2012 08:49 AM, Neil Horman wrote:
>
> Not sure I understand how you came into this error.  If we get an invalid
> stream, we issue an SCTP_REPORT_TSN side effect, followed by an SCTP_CMD_REPLY
> which sends the error chunk.  The reply goes through
> sctp_outq_tail->sctp_outq_chunk->sctp_outq_transmit_chunk->sctp_outq_append_chunk.
> That last function checks to see if a sack is already part of the packet, and if
> there isn't one, appends one, using the updated tsn map.
Yes, you are right, but consider the invalid stream identifier's DATA 
chunk is the first
DATA chunk in the association which will need SACK immediately.
Here is what I thought of the scenario:
     sctp_sf_eat_data_6_2()
         -->sctp_eat_data()
             -->sctp_make_op_error()
             -->sctp_add_cmd_sf(commands, SCTP_CMD_REPLY, SCTP_CHUNK(err))
             -->sctp_outq_tail()          /* First enqueue ERROR chunk */
         -->sctp_add_cmd_sf(commands, SCTP_CMD_GEN_SACK, SCTP_FORCE())
             -->sctp_gen_sack()
                 -->sctp_make_sack()
                 -->sctp_add_cmd_sf(commands, SCTP_CMD_REPLY, 
SCTP_CHUNK(sack))
                 -->sctp_outq_tail()          /* Then enqueue SACK chunk */

So SACK chunk is enqueued after ERROR chunk.
> So Can you explain in
> some more detail how you're getting into this situation?
>    
Actually it's triggered by a customer's test case, but we can also 
reproduce this problem
easily by explicitly contaminating the sctp stack:
--- a/net/sctp/sm_make_chunk.c
+++ b/net/sctp/sm_make_chunk.c
@@ -701,7 +701,7 @@ struct sctp_chunk *sctp_make_datafrag_empty(struct 
sctp_association *asoc,
          * creating the chunk.
          */
         dp.tsn = 0;
-       dp.stream = htons(sinfo->sinfo_stream);
+       dp.stream = htons(sinfo->sinfo_stream) + 10;
         dp.ppid   = sinfo->sinfo_ppid;

         /* Set the flags for an unordered send.  */


Then run sctp_darn application and capture the sctp packet at the same time.



Thanks,
Xufeng Zhang
> Thanks!
> Neil
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>
>    


  reply	other threads:[~2012-07-23  2:23 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-07-19  5:57 [PATCH] sctp: Make "Invalid Stream Identifier" ERROR follows SACK when bundling xufengzhang.main
2012-07-22 19:45 ` David Miller
2012-07-23  0:49 ` Neil Horman
2012-07-23  2:30   ` xufeng zhang [this message]
2012-07-23 12:14     ` Neil Horman
2012-07-24  1:53       ` Xufeng Zhang
     [not found]       ` <500DFF5A.20203@windriver.com>
2012-07-24 11:38         ` Neil Horman
2012-07-25  2:34           ` Xufeng Zhang
2012-07-25 11:15             ` Neil Horman
2012-07-23  5:16 ` xufeng zhang
2012-07-24  2:27   ` Vlad Yasevich
2012-07-24  3:02     ` xufeng zhang
2012-07-24 14:05       ` Vlad Yasevich
2012-07-25  2:28         ` Xufeng Zhang
2012-07-25  7:16           ` Vlad Yasevich
2012-07-25  8:05             ` Xufeng Zhang
2012-07-25  9:22               ` Xufeng Zhang
2012-07-25 11:27                 ` Neil Horman
2012-07-26  1:34                   ` Xufeng Zhang
2012-07-25 15:00                 ` Vlad Yasevich
2012-07-26  1:30                   ` Xufeng Zhang
2012-07-26  2:45                     ` Vlad Yasevich
2012-07-26  2:50                     ` Xufeng Zhang
2012-07-26  2:55                       ` Vlad Yasevich
2012-07-26  3:12                         ` Xufeng Zhang
2012-07-27 21:22                           ` Vlad Yasevich
2012-07-30  4:58                             ` Xufeng Zhang
2012-07-30  5:47                               ` Xufeng Zhang
2012-07-31  6:17                                 ` Xufeng Zhang
2012-07-31  6:51                                   ` xufeng zhang
2012-08-02 21:17                                     ` Vlad Yasevich
2012-08-03  2:24                                       ` xufeng zhang

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=500CB74A.4040300@windriver.com \
    --to=xufeng.zhang@windriver.com \
    --cc=davem@davemloft.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-sctp@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=nhorman@tuxdriver.com \
    --cc=sri@us.ibm.com \
    --cc=vyasevich@gmail.com \
    --cc=xufengzhang.main@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox