Re: [PATCH] sctp: Make "Invalid Stream Identifier" ERROR followsSACK when bundling

From: Vlad Yasevich
Date: Wed Jul 25 2012 - 11:00:57 EST


On 07/25/2012 05:22 AM, Xufeng Zhang wrote:
On 7/25/12, Xufeng Zhang <xufengzhang.main@xxxxxxxxx> wrote:
On 7/25/12, Vlad Yasevich <vyasevich@xxxxxxxxx> wrote:

Actually not true. AUTH can be before SACK. So can any addip chunks
that
aid in locating an association.

Now AUTH isn't a big issue since its autogenerated to the packet but
ADDIP
is since it could be queued up for retransmission.

There could be other extensions as well. It really needs to be done
either
through side effects or making error chunks go at the end of other
control
chunks. Need to audit the spec to see if that's ok.
You are right, I just found SHUTDOWN chunks are also before SACK based on
your commit "[SCTP]: Fix SACK sequence during shutdown".
Maybe the only solution is to do some work on side effects just as you
said.
Thanks for your explanation!

And after take a moment to look into the relative codes, I think we
can implement it
by below way:
1). Add a flag(isi_err_needed) in the embedded struct peer of struct
struct sctp_association
just like sack_needed flag.
2). When "invalid stream identifier" ERROR happens in sctp_eat_data()
function, we just
set isi_err_needed flag and don't create ERROR chunk and also don't
insert SCTP_CMD_REPLY command.
3). In sctp_gen_sack() function, we create ERROR chunk and also insert
SCTP_CMD_REPLY command if isi_err_needed flag is set.

Is this way proper?


So, I looked at the code, and it looks very simple to do. We already return a specific status from sctp_eat_data() when the error was generated. All you have to do is take the code that generates the error and adds it to the command list and give it its own small function that you can then call if SCTP_IERROR_BAD_STREAM error was returned.

-vlad


Thanks,
Xufeng Zhang



Thanks,
Xufeng Zhang

-vlad

Thanks,
Xufeng Zhang

-vlad


--
Sent from my Android phone with SkitMail. Please excuse my brevity.




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