1. 22 Jul, 2008 1 commit
  2. 19 Jul, 2008 1 commit
  3. 19 Jun, 2008 1 commit
    • Vlad Yasevich's avatar
      sctp: Follow security requirement of responding with 1 packet · 2e3216cd
      Vlad Yasevich authored
      
      
      RFC 4960, Section 11.4. Protection of Non-SCTP-Capable Hosts
      
      When an SCTP stack receives a packet containing multiple control or
      DATA chunks and the processing of the packet requires the sending of
      multiple chunks in response, the sender of the response chunk(s) MUST
      NOT send more than one packet.  If bundling is supported, multiple
      response chunks that fit into a single packet MAY be bundled together
      into one single response packet.  If bundling is not supported, then
      the sender MUST NOT send more than one response chunk and MUST
      discard all other responses.  Note that this rule does NOT apply to a
      SACK chunk, since a SACK chunk is, in itself, a response to DATA and
      a SACK does not require a response of more DATA.
      
      We implement this by not servicing our outqueue until we reach the end
      of the packet.  This enables maximum bundling.  We also identify
      'response' chunks and make sure that we only send 1 packet when sending
      such chunks.
      Signed-off-by: default avatarVlad Yasevich <vladislav.yasevich@hp.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      2e3216cd
  4. 04 Jun, 2008 4 commits
  5. 09 May, 2008 1 commit
  6. 24 Mar, 2008 1 commit
  7. 29 Feb, 2008 1 commit
  8. 05 Feb, 2008 1 commit
  9. 28 Jan, 2008 5 commits
  10. 20 Dec, 2007 1 commit
  11. 07 Dec, 2007 1 commit
  12. 09 Nov, 2007 1 commit
  13. 07 Nov, 2007 4 commits
  14. 11 Oct, 2007 1 commit
  15. 10 Oct, 2007 6 commits
  16. 26 Sep, 2007 2 commits
  17. 16 Sep, 2007 2 commits
  18. 30 Aug, 2007 1 commit
    • 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
  19. 13 Jun, 2007 2 commits
  20. 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
  21. 26 Apr, 2007 2 commits