1. 05 9月, 2009 4 次提交
  2. 03 6月, 2009 2 次提交
  3. 03 3月, 2009 2 次提交
  4. 06 1月, 2009 1 次提交
  5. 26 12月, 2008 1 次提交
  6. 31 10月, 2008 1 次提交
  7. 30 10月, 2008 1 次提交
  8. 29 10月, 2008 1 次提交
  9. 23 10月, 2008 2 次提交
  10. 10 10月, 2008 3 次提交
  11. 01 10月, 2008 3 次提交
    • V
      sctp: enable cookie-echo retransmission transport switch · 96cd0d3d
      Vlad Yasevich 提交于
      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: NGui Jianfeng <guijianfeng@cn.fujitsu.com>
      Signed-off-by: NVlad Yasevich <vladislav.yasevich@hp.com>
      96cd0d3d
    • W
      sctp: Fix the SNMP counter of SCTP_MIB_OUTOFBLUES · 8190f89d
      Wei Yongjun 提交于
      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: NWei Yongjun <yjwei@cn.fujitsu.com>
      Signed-off-by: NVlad Yasevich <vladislav.yasevich@hp.com>
      8190f89d
    • W
      sctp: Fix to start T5-shutdown-guard timer while enter SHUTDOWN-SENT state · 536428a9
      Wei Yongjun 提交于
      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: NWei Yongjun <yjwei@cn.fujitsu.com>
      Signed-off-by: NVlad Yasevich <vladislav.yasevich@hp.com>
      536428a9
  12. 30 9月, 2008 1 次提交
  13. 08 7月, 2008 1 次提交
  14. 20 6月, 2008 1 次提交
    • V
      sctp: Follow security requirement of responding with 1 packet · 2e3216cd
      Vlad Yasevich 提交于
      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: NVlad Yasevich <vladislav.yasevich@hp.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      2e3216cd
  15. 13 4月, 2008 3 次提交
  16. 28 3月, 2008 1 次提交
  17. 24 3月, 2008 1 次提交
  18. 06 3月, 2008 1 次提交
  19. 01 3月, 2008 1 次提交
  20. 05 2月, 2008 2 次提交
    • V
      [SCTP]: Stop claiming that this is a "reference implementation" · 60c778b2
      Vlad Yasevich 提交于
      I was notified by Randy Stewart that lksctp claims to be
      "the reference implementation".  First of all, "the
      refrence implementation" was the original implementation
      of SCTP in usersapce written ty Randy and a few others.
      Second, after looking at the definiton of 'reference implementation',
      we don't really meet the requirements.
      Signed-off-by: NVlad Yasevich <vladislav.yasevich@hp.com>
      60c778b2
    • W
      [SCTP]: Fix kernel panic while received AUTH chunk while enabled auth · d2f19fa1
      Wei Yongjun 提交于
      If STCP is started while /proc/sys/net/sctp/auth_enable is set 0 and
      association is established between endpoints. Then if
      /proc/sys/net/sctp/auth_enable is set 1, a received AUTH chunk will
      cause kernel panic.
      
      Test as following:
      step 1: echo 0> /proc/sys/net/sctp/auth_enable
      step 2:
      
         SCTP client                  SCTP server
            INIT          --------->
                          <---------   INIT-ACK
            COOKIE-ECHO   --------->
                          <---------   COOKIE-ACK
      step 3:
          echo 1> /proc/sys/net/sctp/auth_enable
      step 4:
         SCTP client                  SCTP server
             AUTH        ----------->  Kernel Panic
      
      
      This patch fix this probleam to treat AUTH chunk as unknow chunk if peer 
      has initialized with no auth capable.
      
      > Sorry for the delay.  Was on vacation without net access.
      >
      > Wei Yongjun wrote:
      >>
      >>
      >> This patch fix this probleam to treat AUTH chunk as unknow chunk if 
      >> peer has initialized with no auth capable.
      >>
      >> Signed-off-by: Wei Yongjun <yjwei@cn.fujitsu.com>
      >
      > Acked-by: Vlad Yasevich <vladislav.yasevich@hp.com>
      >
      >>
      Signed-off-by: NWei Yongjun <yjwei@cn.fujitsu.com>
      Acked-by: NVlad Yasevich <vladislav.yasevich@hp.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      d2f19fa1
  21. 03 2月, 2008 1 次提交
  22. 29 1月, 2008 6 次提交
    • V
      [SCTP]: Correctly initialize error when parameter validation failed. · 853f4b50
      Vlad Yasevich 提交于
      When parameter validation fails, there should be error causes that
      specify what type of failure we've encountered.  If the causes are not
      there, we lacked memory to allocated them.  Thus make that the default
      value for the error.
      Signed-off-by: NVlad Yasevich <vladislav.yasevich@hp.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      853f4b50
    • D
      [SCTP]: Fix build warning in sctp_sf_do_5_1C_ack(). · 66688ea7
      David S. Miller 提交于
      Reported by Andrew Morton.
      
      net/sctp/sm_statefuns.c: In function 'sctp_sf_do_5_1C_ack':
      net/sctp/sm_statefuns.c:484: warning: 'error' may be used uninitialized in this function
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      66688ea7
    • H
      [NET] CORE: Introducing new memory accounting interface. · 3ab224be
      Hideo Aoki 提交于
      This patch introduces new memory accounting functions for each network
      protocol. Most of them are renamed from memory accounting functions
      for stream protocols. At the same time, some stream memory accounting
      functions are removed since other functions do same thing.
      
      Renaming:
      	sk_stream_free_skb()		->	sk_wmem_free_skb()
      	__sk_stream_mem_reclaim()	->	__sk_mem_reclaim()
      	sk_stream_mem_reclaim()		->	sk_mem_reclaim()
      	sk_stream_mem_schedule 		->    	__sk_mem_schedule()
      	sk_stream_pages()      		->	sk_mem_pages()
      	sk_stream_rmem_schedule()	->	sk_rmem_schedule()
      	sk_stream_wmem_schedule()	->	sk_wmem_schedule()
      	sk_charge_skb()			->	sk_mem_charge()
      
      Removeing
      	sk_stream_rfree():	consolidates into sock_rfree()
      	sk_stream_set_owner_r(): consolidates into skb_set_owner_r()
      	sk_stream_mem_schedule()
      
      The following functions are added.
          	sk_has_account(): check if the protocol supports accounting
      	sk_mem_uncharge(): do the opposite of sk_mem_charge()
      
      In addition, to achieve consolidation, updating sk_wmem_queued is
      removed from sk_mem_charge().
      
      Next, to consolidate memory accounting functions, this patch adds
      memory accounting calls to network core functions. Moreover, present
      memory accounting call is renamed to new accounting call.
      
      Finally we replace present memory accounting calls with new interface
      in TCP and SCTP.
      Signed-off-by: NTakahiro Yasui <tyasui@redhat.com>
      Signed-off-by: NHideo Aoki <haoki@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      3ab224be
    • V
      [SCTP]: Follow Add-IP security consideratiosn wrt INIT/INIT-ACK · d6701191
      Vlad Yasevich 提交于
      The Security Considerations section of RFC 5061 has the following
      text:
      
         If an SCTP endpoint that supports this extension receives an INIT
         that indicates that the peer supports the ASCONF extension but does
         NOT support the [RFC4895] extension, the receiver of such an INIT
         MUST send an ABORT in response.  Note that an implementation is
         allowed to silently discard such an INIT as an option as well, but
         under NO circumstance is an implementation allowed to proceed with
         the association setup by sending an INIT-ACK in response.
      
         An implementation that receives an INIT-ACK that indicates that the
         peer does not support the [RFC4895] extension MUST NOT send the
         COOKIE-ECHO to establish the association.  Instead, the
         implementation MUST discard the INIT-ACK and report to the upper-
         layer user that an association cannot be established destroying the
         Transmission Control Block (TCB).
      
      Follow the recomendations.
      Signed-off-by: NVlad Yasevich <vladislav.yasevich@hp.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      d6701191
    • V
      [SCTP]: Implement ADD-IP special case processing for ABORT chunk · 75205f47
      Vlad Yasevich 提交于
      ADD-IP spec has a special case for processing ABORTs:
          F4) ... One special consideration is that ABORT
              Chunks arriving destined to the IP address being deleted MUST be
              ignored (see Section 5.3.1 for further details).
      
      Check if the address we received on is in the DEL state, and if
      so, ignore the ABORT.
      Signed-off-by: NVlad Yasevich <vladislav.yasevich@hp.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      75205f47
    • V
      [SCTP]: Update ASCONF processing to conform to spec. · a08de64d
      Vlad Yasevich 提交于
      The processing of the ASCONF chunks has changed a lot in the
      spec.  New items are:
          1. A list of ASCONF-ACK chunks is now cached
          2. The source of the packet is used in response.
          3. New handling for unexpect ASCONF chunks.
      Signed-off-by: NVlad Yasevich <vladislav.yasevich@hp.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      a08de64d