Skip to content

L
linux-davinci-2.6.23
An error occurred fetching the project authors.
Switch branch/tag
  1. 30 Aug, 2007 2 commits
    • Wei Yongjun's avatar
      SCTP: Fix to encode PROTOCOL VIOLATION error cause correctly · 00f1c2df
      Wei Yongjun authored 
      PROTOCOL VIOLATION error cause in ABORT is bad encode when make abort
chunk. When SCTP encode ABORT chunk with PROTOCOL VIOLATION error cause,
it just add the error messages to PROTOCOL VIOLATION error cause, the
rest four bytes(struct sctp_paramhdr) is just add to the chunk, not
change the length of error cause. This cause the ABORT chunk to be a bad
format. The chunk is like this:

ABORT chunk
  Chunk type: ABORT (6)
  Chunk flags: 0x00
  Chunk length: 72 (*1)
  Protocol violation cause
    Cause code: Protocol violation (0x000d)
    Cause length: 62 (*2)
    Cause information: 5468652063756D756C61746976652074736E2061636B2062...
    Cause padding: 0000
[Needless] 00030010
Chunk Length(*1) = 72 but Cause length(*2) only 62, not include the
extend 4 bytes.
((72 - sizeof(chunk_hdr)) = 68) != (62 +3) / 4 * 4
Signed-off-by: default avatarWei Yongjun <yjwei@cn.fujitsu.com>
Signed-off-by: default avatarVlad Yasevich <vladislav.yasevich@hp.com>
      00f1c2df
    • Wei Yongjun's avatar
      SCTP: Fix sctp_addto_chunk() to add pad with correct length · 8d614ade
      Wei Yongjun authored 
      At function sctp_addto_chunk(), it do pad before add payload to chunk if
chunk length is not 4-byte alignment. But it do pad with a bad length.
This patch fixed this probleam.
Signed-off-by: default avatarWei Yongjun <yjwei@cn.fujitsu.com>
Signed-off-by: default avatarVlad Yasevich <vladislav.yasevich@hp.com>
      8d614ade
  3. 29 Aug, 2007 1 commit
    • Vlad Yasevich's avatar
      SCTP: Assign stream sequence numbers to the entire message · ab3e5e7b
      Vlad Yasevich authored 
      Currently we only assign the sequence number to a packet that
we are about to transmit.  This however breaks the Partial
Reliability extensions, because it's possible for us to
never transmit a packet, i.e. it expires before we get to send
it.  In such cases, if the message contained multiple SCTP
fragments, and we did manage to send the first part of the
message, the Stream sequence numbers would get into invalid
state and cause receiver to stall.
Signed-off-by: default avatarVlad Yasevich <vladislav.yasevich@hp.com>
      ab3e5e7b
  5. 02 Aug, 2007 1 commit
  7. 01 Aug, 2007 2 commits
  9. 04 May, 2007 1 commit
    • Vlad Yasevich's avatar
      [SCTP]: Set assoc_id correctly during INIT collision. · 07d93967
      Vlad Yasevich authored 
      During the INIT/COOKIE-ACK collision cases, it's possible to get
into a situation where the association id is not yet set at the time
of the user event generation.  As a result, user events have an
association id set to 0 which will confuse applications.

This happens if we hit case B of duplicate cookie processing.
In the particular example found and provided by Oscar Isaula
<Oscar.Isaula@motorola.com>, flow looks like this:
A				B
---- INIT------->  (lost)
	    <---------INIT------
---- INIT-ACK--->
	    <------ Cookie ECHO

When the Cookie Echo is received, we end up trying to update the
association that was created on A as a result of the (lost) INIT,
but that association doesn't have the ID set yet.
Signed-off-by: default avatarVlad Yasevich <vladislav.yasevich@hp.com>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      07d93967
  11. 26 Apr, 2007 3 commits
  13. 11 Feb, 2007 2 commits
  15. 24 Jan, 2007 2 commits
  17. 09 Jan, 2007 1 commit
  19. 22 Dec, 2006 1 commit
  21. 07 Dec, 2006 2 commits
  23. 03 Dec, 2006 22 commits