Skip to content

GitLab

Switch branch/tag
  1. 30 Aug, 2007 2 commits
    • Wei Yongjun's avatar
      SCTP: Use net_ratelimit to suppress error messages print too fast · d99fa429
      Wei Yongjun authored 
      
When multi bundling SHUTDOWN-ACK message is received in ESTAB state,
this will cause "sctp protocol violation state" message print many times.
If SHUTDOWN-ACK is bundled 300 times in one packet, message will be
print 300 times. The same problem also exists when received unexpected
HEARTBEAT-ACK message which is bundled message times.

This patch used net_ratelimit() to suppress error messages print too fast.
Signed-off-by: default avatarWei Yongjun <yjwei@cn.fujitsu.com>
Signed-off-by: default avatarVlad Yasevich <vladislav.yasevich@hp.com>
      d99fa429
    • 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
  3. 02 Aug, 2007 1 commit
  5. 18 Jul, 2007 1 commit
  7. 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
  9. 26 Apr, 2007 4 commits
  11. 20 Mar, 2007 1 commit
  13. 26 Feb, 2007 1 commit
  15. 11 Feb, 2007 1 commit
  17. 24 Jan, 2007 1 commit
  19. 23 Jan, 2007 2 commits
  21. 22 Dec, 2006 1 commit
  23. 03 Dec, 2006 15 commits
  25. 22 Sep, 2006 2 commits
  27. 22 Aug, 2006 1 commit
  29. 21 Jul, 2006 2 commits
  31. 18 Jun, 2006 1 commit
    • Neil Horman's avatar
      [SCTP]: Fix persistent slowdown in sctp when a gap ack consumes rx buffer. · d5b9f4c0
      Neil Horman authored 
      
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: default avatarNeil Horman <nhorman@tuxdriver.com>
Signed-off-by: default avatarSridhar Samudrala <sri@us.ibm.com>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      d5b9f4c0
  33. 19 May, 2006 2 commits
  35. 05 May, 2006 1 commit