1. 03 6月, 2009 1 次提交
    • W
      sctp: fix report unrecognized parameter in ACSONF-ACK · a987f762
      Wei Yongjun 提交于
      RFC5061 Section 5.2.  Upon Reception of an ASCONF Chunk
      
      V2)  In processing the chunk, the receiver should build a
           response message with the appropriate error TLVs, as
           specified in the Parameter type bits, for any ASCONF
           Parameter it does not understand.  To indicate an
           unrecognized parameter, Cause Type 8 should be used as
           defined in the ERROR in Section 3.3.10.8, [RFC4960].  The
           endpoint may also use the response to carry rejections for
           other reasons, such as resource shortages, etc., using the
           Error Cause TLV and an appropriate error condition.
      
      So we should indicate an unrecognized parameter with error
      SCTP_ERROR_UNKNOWN_PARAM in ACSONF-ACK chunk, not
      SCTP_ERROR_INV_PARAM.
      Signed-off-by: NWei Yongjun <yjwei@cn.fujitsu.com>
      Signed-off-by: NVlad Yasevich <vladislav.yasevich@hp.com>
      a987f762
  2. 14 3月, 2009 2 次提交
  3. 01 2月, 2009 1 次提交
  4. 09 10月, 2008 2 次提交
    • V
      sctp: shrink sctp_tsnmap some more by removing gabs array · 02015180
      Vlad Yasevich 提交于
      The gabs array in the sctp_tsnmap structure is only used
      in one place, sctp_make_sack().  As such, carrying the
      array around in the sctp_tsnmap and thus directly in
      the sctp_association is rather pointless since most
      of the time it's just taking up space.  Now, let
      sctp_make_sack create and populate it and then throw
      it away when it's done.
      Signed-off-by: NVlad Yasevich <vladislav.yasevich@hp.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      02015180
    • V
      sctp: Rework the tsn map to use generic bitmap. · 8e1ee18c
      Vlad Yasevich 提交于
      The tsn map currently use is 4K large and is stuck inside
      the sctp_association structure making memory references REALLY
      expensive.  What we really need is at most 4K worth of bits
      so the biggest map we would have is 512 bytes.   Also, the
      map is only really usefull when we have gaps to store and
      report.  As such, starting with minimal map of say 32 TSNs (bits)
      should be enough for normal low-loss operations.  We can grow
      the map by some multiple of 32 along with some extra room any
      time we receive the TSN which would put us outside of the map
      boundry.  As we close gaps, we can shift the map to rebase
      it on the latest TSN we've seen.  This saves 4088 bytes per
      association just in the map alone along savings from the now
      unnecessary structure members.
      Signed-off-by: NVlad Yasevich <vladislav.yasevich@hp.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      8e1ee18c
  5. 01 10月, 2008 2 次提交
  6. 30 9月, 2008 1 次提交
  7. 19 9月, 2008 2 次提交
    • V
      sctp: Fix oops when INIT-ACK indicates that peer doesn't support AUTH · add52379
      Vlad Yasevich 提交于
      If INIT-ACK is received with SupportedExtensions parameter which
      indicates that the peer does not support AUTH, the packet will be
      silently ignore, and sctp_process_init() do cleanup all of the
      transports in the association.
      When T1-Init timer is expires, OOPS happen while we try to choose
      a different init transport.
      
      The solution is to only clean up the non-active transports, i.e
      the ones that the peer added.  However, that introduces a problem
      with sctp_connectx(), because we don't mark the proper state for
      the transports provided by the user.  So, we'll simply mark
      user-provided transports as ACTIVE.  That will allow INIT
      retransmissions to work properly in the sctp_connectx() context
      and prevent the crash.
      Signed-off-by: NVlad Yasevich <vladislav.yasevich@hp.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      add52379
    • V
      sctp: do not enable peer features if we can't do them. · 0ef46e28
      Vlad Yasevich 提交于
      Do not enable peer features like addip and auth, if they
      are administratively disabled localy.  If the peer resports
      that he supports something that we don't, neither end can
      use it so enabling it is pointless.  This solves a problem
      when talking to a peer that has auth and addip enabled while
      we do not.  Found by Andrei Pelinescu-Onciul <andrei@iptel.org>.
      Signed-off-by: NVlad Yasevich <vladislav.yasevich@hp.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      0ef46e28
  8. 19 7月, 2008 1 次提交
  9. 14 5月, 2008 1 次提交
  10. 12 5月, 2008 2 次提交
  11. 13 4月, 2008 2 次提交
  12. 24 3月, 2008 1 次提交
  13. 06 3月, 2008 1 次提交
    • G
      SCTP: Fix chunk parameter processing bug · 140ee960
      Gui Jianfeng 提交于
      If an address family is not listed in "Supported Address Types"
      parameter(INIT Chunk), but the packet is sent by that family, this
      address family should be considered as supported by peer.  Otherwise,
      an error condition will occur. For instance, if kernel receives an
      IPV6 SCTP INIT chunk with "Support Address Types" parameter which
      indicates just supporting IPV4 Address family. Kernel will reply an
      IPV6 SCTP INIT ACK packet, but the source ipv6 address in ipv6 header
      will be vacant. This is not correct.
      
      refer to RFC4460 as following:
            IMPLEMENTATION NOTE: If an SCTP endpoint lists in the 'Supported
            Address Types' parameter either IPv4 or IPv6, but uses the other
            family for sending the packet containing the INIT chunk, or if it
            also lists addresses of the other family in the INIT chunk, then
            the address family that is not listed in the 'Supported Address
            Types' parameter SHOULD also be considered as supported by the
            receiver of the INIT chunk.  The receiver of the INIT chunk SHOULD
            NOT respond with any kind of error indication.
      
      Here is a fix to comply to RFC.
      Signed-off-by: NGui Jianfeng <guijianfeng@cn.fujitsu.com>
      Acked-by: NVlad Yasevich <vladislav.yasevich@hp.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      140ee960
  14. 07 2月, 2008 1 次提交
  15. 05 2月, 2008 1 次提交
  16. 01 2月, 2008 1 次提交
  17. 29 1月, 2008 5 次提交
  18. 09 1月, 2008 1 次提交
  19. 21 12月, 2007 1 次提交
  20. 29 11月, 2007 2 次提交
  21. 10 11月, 2007 1 次提交
  22. 08 11月, 2007 4 次提交
  23. 27 10月, 2007 1 次提交
  24. 24 10月, 2007 1 次提交
  25. 23 10月, 2007 2 次提交