- 03 6月, 2009 1 次提交
-
-
由 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>
-
- 14 3月, 2009 2 次提交
-
-
由 malc 提交于
RFC5061 states: Each adaptation layer that is defined that wishes to use this parameter MUST specify an adaptation code point in an appropriate RFC defining its use and meaning. If the user has not set one - assume they don't want to sent the param with a zero Adaptation Code Point. Rationale - Currently the IANA defines zero as reserved - and 1 as the only valid value - so we consider zero to be unset - to save adding a boolean to the socket structure. Including this parameter unconditionally causes endpoints that do not understand it to report errors unnecessarily. Signed-off-by: NMalcolm Lashley <mlashley@gmail.com> Signed-off-by: NVlad Yasevich <vladislav.yasevich@hp.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Wei Yongjun 提交于
This patch fix to indicate ASCONF support in INIT-ACK only if peer has such capable. This patch also fix to calc the chunk size if peer has no FWD-TSN capable. Signed-off-by: NWei Yongjun <yjwei@cn.fujitsu.com> Signed-off-by: NVlad Yasevich <vladislav.yasevich@hp.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 01 2月, 2009 1 次提交
-
-
由 Harvey Harrison 提交于
Base versions handle constant folding now. Signed-off-by: NHarvey Harrison <harvey.harrison@gmail.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 09 10月, 2008 2 次提交
-
-
由 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>
-
由 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>
-
- 01 10月, 2008 2 次提交
-
-
由 Vlad Yasevich 提交于
The INIT perameter carries the adapatation value in network-byte order. We need to store it in host byte order as expected by data types and the user API. Signed-off-by: NVlad Yasevich <vladislav.yasevich@hp.com>
-
由 Neil Horman 提交于
sctp_chunks should be put on a diet. This is some of the low hanging fruit that we can strip out. Changes all the __s8/__u8 flags to bitfields. Saves 12 bytes per chunk. Signed-off-by: NNeil Horman <nhorman@tuxdriver.com> Signed-off-by: NVlad Yasevich <vladislav.yasevich@hp.com>
-
- 30 9月, 2008 1 次提交
-
-
由 Wei Yongjun 提交于
Since call to function sctp_sf_abort_violation() need paramter 'arg' with 'struct sctp_chunk' type, it will read the chunk type and chunk length from the chunk_hdr member of chunk. But call to sctp_sf_violation_paramlen() always with 'struct sctp_paramhdr' type's parameter, it will be passed to sctp_sf_abort_violation(). This may cause kernel panic. sctp_sf_violation_paramlen() |-- sctp_sf_abort_violation() |-- sctp_make_abort_violation() This patch fixed this problem. This patch also fix two place which called sctp_sf_violation_paramlen() with wrong paramter type. Signed-off-by: NWei Yongjun <yjwei@cn.fujitsu.com> Signed-off-by: NVlad Yasevich <vladislav.yasevich@hp.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 19 9月, 2008 2 次提交
-
-
由 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>
-
由 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>
-
- 19 7月, 2008 1 次提交
-
-
由 Vlad Yasevich 提交于
Signed-off-by: NVlad Yasevich <vladislav.yasevich@hp.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 14 5月, 2008 1 次提交
-
-
由 Patrick McHardy 提交于
Introduced by c4492586 (sctp: Add address type check while process paramaters of ASCONF chunk): net/sctp/sm_make_chunk.c: In function 'sctp_process_asconf': net/sctp/sm_make_chunk.c:2828: warning: 'addr_param' may be used uninitialized in this function net/sctp/sm_make_chunk.c:2828: note: 'addr_param' was declared here Signed-off-by: NPatrick McHardy <kaber@trash.net> Acked-by: NVlad Yasevich <vladislav.yasevich@hp.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 12 5月, 2008 2 次提交
-
-
由 Wei Yongjun 提交于
If socket is create by AF_INET type, add IPv6 address to asoc will cause kernel panic while packet is transmitted on that transport. This patch add address type check before process paramaters of ASCONF chunk. If peer is not support this address type, return with error invald parameter. Signed-off-by: NWei Yongjun <yjwei@cn.fujitsu.com> Signed-off-by: NVlad Yasevich <vladislav.yasevich@hp.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Wei Yongjun 提交于
If socket is create by PF_INET type, it can not used IPv6 address to send/recv DATA, So we can not used IPv6 address even if peer tell us it support IPv6 address. This patch fix to only enabled peer IPv6 address support on PF_INET6 socket. Signed-off-by: NWei Yongjun <yjwei@cn.fujitsu.com> Signed-off-by: NVlad Yasevich <vladislav.yasevich@hp.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 13 4月, 2008 2 次提交
-
-
由 Robert P. J. Day 提交于
Replacing (almost) all invocations of list_for_each() with list_for_each_entry() tightens up the code and allows for the deletion of numerous list iterator variables that are no longer necessary. Signed-off-by: NRobert P. J. Day <rpjday@crashcourse.ca> Signed-off-by: NVlad Yasevich <vladislav.yasevich@hp.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Wei Yongjun 提交于
RFC 4890 has the following text: The HMAC algorithm based on SHA-1 MUST be supported and included in the HMAC-ALGO parameter. As a result, we need to check in sctp_verify_param() that HMAC_SHA1 is present in the list. If not, we should probably treat this as a protocol violation. It should also be a protocol violation if the HMAC parameter is empty. Signed-off-by: NWei Yongjun <yjwei@cn.fujitsu.com> Signed-off-by: NVlad Yasevich <vladislav.yasevich@hp.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 24 3月, 2008 1 次提交
-
-
由 Florian Westphal 提交于
133886 2004 220 136110 213ae sctp.new/sctp.o 134018 2004 220 136242 21432 sctp.old/sctp.o Signed-off-by: NFlorian Westphal <fw@strlen.de> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 06 3月, 2008 1 次提交
-
-
由 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>
-
- 07 2月, 2008 1 次提交
-
-
由 Vlad Yasevich 提交于
In a few instances, we need to remove the chunk from the transmitted list prior to freeing it. This is because the free code doesn't do that any more and so we need to do it manually. Signed-off-by: NVlad Yasevich <vladislav.yasevich@hp.com>
-
- 05 2月, 2008 1 次提交
-
-
由 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>
-
- 01 2月, 2008 1 次提交
-
-
由 Wei Yongjun 提交于
This patch fix miss of check for report unrecognized HMAC Algorithm parameter. When AUTH is disabled, goto fall through path to report unrecognized parameter, else, just break Signed-off-by: NWei Yongjun <yjwei@cn.fujitsu.com> Acked-by: NNeil Horman <nhorman@tuxdriver.com> Acked-by: NVlad Yasevich <vladislav.yasevich@hp.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 29 1月, 2008 5 次提交
-
-
由 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>
-
由 Vlad Yasevich 提交于
Signed-off-by: NVlad Yasevich <vladislav.yasevich@hp.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 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>
-
由 Vlad Yasevich 提交于
The ADD-IP "Set Primary IP Address" parameter is allowed in the INIT/INIT-ACK exchange. Allow processing of this parameter during the INIT/INIT-ACK. Signed-off-by: NVlad Yasevich <vladislav.yasevich@hp.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Vlad Yasevich 提交于
The Address Parameter in the parameter list of the ASCONF chunk may be a wildcard address. In this case special processing is required. For the 'add' case, the source IP of the packet is added. In the 'del' case, all addresses except the source IP of packet are removed. In the "mark primary" case, the source address is marked as primary. Signed-off-by: NVlad Yasevich <vladislav.yasevich@hp.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 09 1月, 2008 1 次提交
-
-
由 Vlad Yasevich 提交于
Some recent changes completely removed accounting for the FORWARD_TSN parameter length in the INIT and INIT-ACK chunk. This is wrong and should be restored. Signed-off-by: NVlad Yasevich <vladislav.yasevich@hp.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 21 12月, 2007 1 次提交
-
-
由 Joe Perches 提交于
Signed-off-by: NJoe Perches <joe@perches.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 29 11月, 2007 2 次提交
-
-
由 Vlad Yasevich 提交于
Supported extensions parameter was not coded right and ended up over-writing memory or causing skb overflows. First, remove the FWD_TSN support from as it shouldn't be there and also fix the paramter encoding. Signed-off-by: NVlad Yasevich <vladislav.yasevich@hp.com>
-
由 Vlad Yasevich 提交于
There was a typo that cleared the HMACS parameters when no authenticated chunks were specified. We whould be clearing the chunks pointer instead of the hmacs. Signed-off-by: NVlad Yasevich <vladislav.yasevich@hp.com>
-
- 10 11月, 2007 1 次提交
-
-
由 Vlad Yasevich 提交于
SCTP-AUTH and future ADD-IP updates have a requirement to do additional verification of parameters and an ability to ABORT the association if verification fails. So, introduce additional return code so that we can clear signal a required action. Signed-off-by: NVlad Yasevich <vladislav.yasevich@hp.com>
-
- 08 11月, 2007 4 次提交
-
-
由 Vlad Yasevich 提交于
This patch adds a tunable that will allow ADD_IP to work without AUTH for backward compatibility. The default value is off since the default value for ADD_IP is off as well. People who need to use ADD-IP with older implementations take risks of connection hijacking and should consider upgrading or turning this tunable on. Signed-off-by: NVlad Yasevich <vladislav.yasevich@hp.com>
-
由 Vlad Yasevich 提交于
Signed-off-by: NVlad Yasevich <vladislav.yasevich@hp.com>
-
由 Vlad Yasevich 提交于
After learning more about rcu, it looks like the ADD-IP hadling doesn't need to call call_rcu_bh. All the rcu critical sections use rcu_read_lock, so using call_rcu_bh is wrong here. Now, restore the local_bh_disable() code blocks and use normal call_rcu() calls. Also restore the missing return statement. Signed-off-by: NVlad Yasevich <vladislav.yasevich@hp.com>
-
由 Wei Yongjun 提交于
If ASCONF chunk is bundled with other chunks as the first chunk, when process the ASCONF parameters, full packet data will be process as the parameters of the ASCONF chunk, not only the real parameters. So if you send a ASCONF chunk bundled with other chunks, you will get an unexpect result. This problem also exists when ASCONF-ACK chunk is bundled with other chunks. This patch fix this problem. Signed-off-by: NWei Yongjun <yjwei@cn.fujitsu.com> Signed-off-by: NVlad Yasevich <vladislav.yasevich@hp.com>
-
- 27 10月, 2007 1 次提交
-
-
由 Herbert Xu 提交于
This patch fixes the errors made in the users of the crypto layer during the sg_init_table conversion. It also adds a few conversions that were missing altogether. Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 24 10月, 2007 1 次提交
-
-
由 Jens Axboe 提交于
Most drivers need to set length and offset as well, so may as well fold those three lines into one. Add sg_assign_page() for those two locations that only needed to set the page, where the offset/length is set outside of the function context. Signed-off-by: NJens Axboe <jens.axboe@oracle.com>
-
- 23 10月, 2007 2 次提交
-
-
由 Christian Borntraeger 提交于
sctp fails to compile with net/sctp/sm_make_chunk.c: In function 'sctp_pack_cookie': net/sctp/sm_make_chunk.c:1516: error: implicit declaration of function 'sg_init_table' net/sctp/sm_make_chunk.c:1517: error: implicit declaration of function 'sg_set_page' use the proper include file. SCTP maintainers Vlad Yasevich and Sridhar Samudrala are CCed. Signed-off-by: NChristian Borntraeger <borntraeger@de.ibm.com> Signed-off-by: NJens Axboe <jens.axboe@oracle.com>
-
由 Jens Axboe 提交于
Signed-off-by: NJens Axboe <jens.axboe@oracle.com>
-