Skip to content

K
kernel_linux

OpenHarmony / kernel_linux
上一次同步 3 年多

通知 13
Star 8
Fork 2
K
kernel_linux
切换分支/标签
  1. 11 10月, 2007 2 次提交
    • V
      [SCTP]: Implement the Supported Extensions Parameter · 131a47e3
      由 Vlad Yasevich 提交于 
      SCTP Supported Extenions parameter is specified in Section 4.2.7
of the ADD-IP draft (soon to be RFC).  The parameter is
encoded as:

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     Parameter Type = 0x8008   |      Parameter Length         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | CHUNK TYPE 1  |  CHUNK TYPE 2 |  CHUNK TYPE 3 |  CHUNK TYPE 4 |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                             ....                              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | CHUNK TYPE N  |      PAD      |      PAD      |      PAD      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

It contains a list of chunks that a particular SCTP extension
uses.  Current extensions supported are Partial Reliability
(FWD-TSN) and ADD-IP (ASCONF and ASCONF-ACK).

When implementing new extensions (AUTH, PKT-DROP, etc..), new
chunks need to be added to this parameter.  Parameter processing
would be modified to negotiate support for these new features.
Signed-off-by: NVlad Yasevich <vladislav.yasevich@hp.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      131a47e3
    • A
      [SCTP]: Make sctp_addto_param() static. · 5c94bf86
      由 Adrian Bunk 提交于 
      sctp_addto_param() can become static.
Signed-off-by: NAdrian Bunk <bunk@kernel.org>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      5c94bf86
  3. 27 9月, 2007 1 次提交
  5. 26 9月, 2007 1 次提交
  7. 17 9月, 2007 2 次提交
  9. 31 8月, 2007 1 次提交
    • W
      SCTP: Fix to encode PROTOCOL VIOLATION error cause correctly · 00f1c2df
      由 Wei Yongjun 提交于 
      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: NWei Yongjun <yjwei@cn.fujitsu.com>
Signed-off-by: NVlad Yasevich <vladislav.yasevich@hp.com>
      00f1c2df
  11. 14 6月, 2007 2 次提交
  13. 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
  15. 26 4月, 2007 3 次提交
  17. 20 3月, 2007 1 次提交
  19. 23 12月, 2006 1 次提交
  21. 14 12月, 2006 2 次提交
  23. 03 12月, 2006 15 次提交
  25. 22 11月, 2006 1 次提交
  27. 23 9月, 2006 1 次提交
  29. 21 9月, 2006 1 次提交
  31. 22 7月, 2006 2 次提交
  33. 18 6月, 2006 1 次提交
  35. 06 5月, 2006 1 次提交
  37. 21 3月, 2006 1 次提交