1. 02 8月, 2007 1 次提交
  2. 19 7月, 2007 1 次提交
  3. 05 5月, 2007 1 次提交
    • V
      [SCTP]: Set assoc_id correctly during INIT collision. · 07d93967
      Vlad Yasevich 提交于
      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: NVlad Yasevich <vladislav.yasevich@hp.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      07d93967
  4. 26 4月, 2007 4 次提交
  5. 20 3月, 2007 1 次提交
  6. 27 2月, 2007 1 次提交
  7. 11 2月, 2007 1 次提交
  8. 24 1月, 2007 3 次提交
  9. 23 12月, 2006 1 次提交
  10. 03 12月, 2006 15 次提交
  11. 23 9月, 2006 2 次提交
  12. 23 8月, 2006 1 次提交
  13. 22 7月, 2006 2 次提交
  14. 18 6月, 2006 1 次提交
    • N
      [SCTP]: Fix persistent slowdown in sctp when a gap ack consumes rx buffer. · d5b9f4c0
      Neil Horman 提交于
      In the event that our entire receive buffer is full with a series of
      chunks that represent a single gap-ack, and then we accept a chunk
      (or chunks) that fill in the gap between the ctsn and the first gap,
      we renege chunks from the end of the buffer, which effectively does
      nothing but move our gap to the end of our received tsn stream. This
      does little but move our missing tsns down stream a little, and, if the
      sender is sending sufficiently large retransmit frames, the result is a
      perpetual slowdown which can never be recovered from, since the only
      chunk that can be accepted to allow progress in the tsn stream necessitates
      that a new gap be created to make room for it. This leads to a constant
      need for retransmits, and subsequent receiver stalls. The fix I've come up
      with is to deliver the frame without reneging if we have a full receive
      buffer and the receiving sockets sk_receive_queue is empty(indicating that
      the receive buffer is being blocked by a missing tsn).
      Signed-off-by: NNeil Horman <nhorman@tuxdriver.com>
      Signed-off-by: NSridhar Samudrala <sri@us.ibm.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      d5b9f4c0
  15. 20 5月, 2006 2 次提交
  16. 06 5月, 2006 2 次提交
  17. 31 1月, 2006 1 次提交