1. 08 Oct, 2008 7 commits
  2. 07 Oct, 2008 18 commits
  3. 06 Oct, 2008 3 commits
  4. 05 Oct, 2008 8 commits
  5. 01 Oct, 2008 4 commits
    • Vlad Yasevich's avatar
      sctp: correctly save sctp_adaptation from parameter. · e69c4e0f
      Vlad Yasevich authored
      The INIT perameter carries the adapatation value in network-byte
      order.  We need to store it in host byte order as expected
      by data types and the user API.
      Signed-off-by: default avatarVlad Yasevich <vladislav.yasevich@hp.com>
      e69c4e0f
    • Vlad Yasevich's avatar
      sctp: enable cookie-echo retransmission transport switch · 96cd0d3d
      Vlad Yasevich authored
      This patch enables cookie-echo retransmission transport switch
      feature. If COOKIE-ECHO retransmission happens, it will be sent
      to the address other than the one last sent to.
      Signed-off-by: default avatarGui Jianfeng <guijianfeng@cn.fujitsu.com>
      Signed-off-by: default avatarVlad Yasevich <vladislav.yasevich@hp.com>
      96cd0d3d
    • Wei Yongjun's avatar
      sctp: Fix the SNMP counter of SCTP_MIB_OUTOFBLUES · 8190f89d
      Wei Yongjun authored
      RFC3873 defined SCTP_MIB_OUTOFBLUES:
      
       sctpOutOfBlues OBJECT-TYPE
         SYNTAX         Counter32
         MAX-ACCESS     read-only
         STATUS         current
         DESCRIPTION
              "The number of out of the blue packets received by the host.
              An out of the blue packet is an SCTP packet correctly formed,
              including the proper checksum, but for which the receiver was
              unable to identify an appropriate association."
         REFERENCE
              "Section 8.4 in RFC2960 deals with the Out-Of-The-Blue
               (OOTB) packet definition and procedures."
      
      But OOTB packet INIT, INIT-ACK and SHUTDOWN-ACK(COOKIE-WAIT or
      COOKIE-ECHOED state) are not counted by SCTP_MIB_OUTOFBLUES.
      
      Case 1(INIT):
      
      Endpoint A               Endpoint B
      (CLOSED)                 (CLOSED)
      
       INIT     ---------->
                <----------    ABORT
      
      Case 2(INIT-ACK):
      
      Endpoint A               Endpoint B
      (CLOSED)                 (CLOSED)
      
       INIT-ACK  ---------->
                 <----------   ABORT
      
      Case 3(SHUTDOWN-ACK):
      
      Endpoint A               Endpoint B
      (CLOSED)                 (CLOSED)
      
                <----------    INIT
       SHUTDOWN-ACK  ---------->
                 <----------   SHUTDOWN-COMPLETE
      
      Case 4(SHUTDOWN-ACK):
      
      Endpoint A               Endpoint B
      (CLOSED)                 (COOKIE-ECHOED)
      
       SHUTDOWN-ACK  ---------->
                 <----------   SHUTDOWN-COMPLETE
      
      This patch fixed the problem.
      Signed-off-by: default avatarWei Yongjun <yjwei@cn.fujitsu.com>
      Signed-off-by: default avatarVlad Yasevich <vladislav.yasevich@hp.com>
      8190f89d
    • Wei Yongjun's avatar
      sctp: Fix to start T5-shutdown-guard timer while enter SHUTDOWN-SENT state · 536428a9
      Wei Yongjun authored
      RFC 4960: Section 9.2
      The sender of the SHUTDOWN MAY also start an overall guard timer
      'T5-shutdown-guard' to bound the overall time for the shutdown
      sequence.  At the expiration of this timer, the sender SHOULD abort
      the association by sending an ABORT chunk.  If the 'T5-shutdown-
      guard' timer is used, it SHOULD be set to the recommended value of 5
      times 'RTO.Max'.
      
      The timer 'T5-shutdown-guard' is used to counter the overall time
      for shutdown sequence, and it's start by the sender of the SHUTDOWN.
      So timer 'T5-shutdown-guard' should be start when we send the first
      SHUTDOWN chunk and enter the SHUTDOWN-SENT state, not start when we
      receipt of the SHUTDOWN primitive and enter SHUTDOWN-PENDING state.
      
      If 'T5-shutdown-guard' timer is start at SHUTDOWN-PENDING state, the
      association may be ABORT while data is still transmitting.
      Signed-off-by: default avatarWei Yongjun <yjwei@cn.fujitsu.com>
      Signed-off-by: default avatarVlad Yasevich <vladislav.yasevich@hp.com>
      536428a9