2019-05-27 09:55:01 +03:00
// SPDX-License-Identifier: GPL-2.0-or-later
2005-08-10 07:14:34 +04:00
/*
* net / dccp / input . c
2006-12-10 21:01:18 +03:00
*
2005-08-10 07:14:34 +04:00
* An implementation of the DCCP protocol
* Arnaldo Carvalho de Melo < acme @ conectiva . com . br >
*/
# include <linux/dccp.h>
# include <linux/skbuff.h>
include cleanup: Update gfp.h and slab.h includes to prepare for breaking implicit slab.h inclusion from percpu.h
percpu.h is included by sched.h and module.h and thus ends up being
included when building most .c files. percpu.h includes slab.h which
in turn includes gfp.h making everything defined by the two files
universally available and complicating inclusion dependencies.
percpu.h -> slab.h dependency is about to be removed. Prepare for
this change by updating users of gfp and slab facilities include those
headers directly instead of assuming availability. As this conversion
needs to touch large number of source files, the following script is
used as the basis of conversion.
http://userweb.kernel.org/~tj/misc/slabh-sweep.py
The script does the followings.
* Scan files for gfp and slab usages and update includes such that
only the necessary includes are there. ie. if only gfp is used,
gfp.h, if slab is used, slab.h.
* When the script inserts a new include, it looks at the include
blocks and try to put the new include such that its order conforms
to its surrounding. It's put in the include block which contains
core kernel includes, in the same order that the rest are ordered -
alphabetical, Christmas tree, rev-Xmas-tree or at the end if there
doesn't seem to be any matching order.
* If the script can't find a place to put a new include (mostly
because the file doesn't have fitting include block), it prints out
an error message indicating which .h file needs to be added to the
file.
The conversion was done in the following steps.
1. The initial automatic conversion of all .c files updated slightly
over 4000 files, deleting around 700 includes and adding ~480 gfp.h
and ~3000 slab.h inclusions. The script emitted errors for ~400
files.
2. Each error was manually checked. Some didn't need the inclusion,
some needed manual addition while adding it to implementation .h or
embedding .c file was more appropriate for others. This step added
inclusions to around 150 files.
3. The script was run again and the output was compared to the edits
from #2 to make sure no file was left behind.
4. Several build tests were done and a couple of problems were fixed.
e.g. lib/decompress_*.c used malloc/free() wrappers around slab
APIs requiring slab.h to be added manually.
5. The script was run on all .h files but without automatically
editing them as sprinkling gfp.h and slab.h inclusions around .h
files could easily lead to inclusion dependency hell. Most gfp.h
inclusion directives were ignored as stuff from gfp.h was usually
wildly available and often used in preprocessor macros. Each
slab.h inclusion directive was examined and added manually as
necessary.
6. percpu.h was updated not to include slab.h.
7. Build test were done on the following configurations and failures
were fixed. CONFIG_GCOV_KERNEL was turned off for all tests (as my
distributed build env didn't work with gcov compiles) and a few
more options had to be turned off depending on archs to make things
build (like ipr on powerpc/64 which failed due to missing writeq).
* x86 and x86_64 UP and SMP allmodconfig and a custom test config.
* powerpc and powerpc64 SMP allmodconfig
* sparc and sparc64 SMP allmodconfig
* ia64 SMP allmodconfig
* s390 SMP allmodconfig
* alpha SMP allmodconfig
* um on x86_64 SMP allmodconfig
8. percpu.h modifications were reverted so that it could be applied as
a separate patch and serve as bisection point.
Given the fact that I had only a couple of failures from tests on step
6, I'm fairly confident about the coverage of this conversion patch.
If there is a breakage, it's likely to be something in one of the arch
headers which should be easily discoverable easily on most builds of
the specific arch.
Signed-off-by: Tejun Heo <tj@kernel.org>
Guess-its-ok-by: Christoph Lameter <cl@linux-foundation.org>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
2010-03-24 11:04:11 +03:00
# include <linux/slab.h>
2005-08-10 07:14:34 +04:00
# include <net/sock.h>
2005-09-18 11:17:51 +04:00
# include "ackvec.h"
2005-08-10 07:14:34 +04:00
# include "ccid.h"
# include "dccp.h"
2007-10-18 06:33:06 +04:00
/* rate-limit for syncs in reply to sequence-invalid packets; RFC 4340, 7.5.4 */
int sysctl_dccp_sync_ratelimit __read_mostly = HZ / 8 ;
2007-12-13 16:28:43 +03:00
static void dccp_enqueue_skb ( struct sock * sk , struct sk_buff * skb )
2005-08-10 07:14:34 +04:00
{
__skb_pull ( skb , dccp_hdr ( skb ) - > dccph_doff * 4 ) ;
__skb_queue_tail ( & sk - > sk_receive_queue , skb ) ;
skb_set_owner_r ( skb , sk ) ;
2014-04-12 00:15:36 +04:00
sk - > sk_data_ready ( sk ) ;
2005-08-10 07:14:34 +04:00
}
2007-12-13 16:28:43 +03:00
static void dccp_fin ( struct sock * sk , struct sk_buff * skb )
{
/*
* On receiving Close / CloseReq , both RD / WR shutdown are performed .
* RFC 4340 , 8.3 says that we MAY send further Data / DataAcks after
* receiving the closing segment , but there is no guarantee that such
* data will be processed at all .
*/
sk - > sk_shutdown = SHUTDOWN_MASK ;
sock_set_flag ( sk , SOCK_DONE ) ;
dccp_enqueue_skb ( sk , skb ) ;
}
[DCCP]: Integrate state transitions for passive-close
This adds the necessary state transitions for the two forms of passive-close
* PASSIVE_CLOSE - which is entered when a host receives a Close;
* PASSIVE_CLOSEREQ - which is entered when a client receives a CloseReq.
Here is a detailed account of what the patch does in each state.
1) Receiving CloseReq
The pseudo-code in 8.5 says:
Step 13: Process CloseReq
If P.type == CloseReq and S.state < CLOSEREQ,
Generate Close
S.state := CLOSING
Set CLOSING timer.
This means we need to address what to do in CLOSED, LISTEN, REQUEST, RESPOND, PARTOPEN, and OPEN.
* CLOSED: silently ignore - it may be a late or duplicate CloseReq;
* LISTEN/RESPOND: will not appear, since Step 7 is performed first (we know we are the client);
* REQUEST: perform Step 13 directly (no need to enqueue packet);
* OPEN/PARTOPEN: enter PASSIVE_CLOSEREQ so that the application has a chance to process unread data.
When already in PASSIVE_CLOSEREQ, no second CloseReq is enqueued. In any other state, the CloseReq is ignored.
I think that this offers some robustness against rare and pathological cases: e.g. a simultaneous close where
the client sends a Close and the server a CloseReq. The client will then be retransmitting its Close until it
gets the Reset, so ignoring the CloseReq while in state CLOSING is sane.
2) Receiving Close
The code below from 8.5 is unconditional.
Step 14: Process Close
If P.type == Close,
Generate Reset(Closed)
Tear down connection
Drop packet and return
Thus we need to consider all states:
* CLOSED: silently ignore, since this can happen when a retransmitted or late Close arrives;
* LISTEN: dccp_rcv_state_process() will generate a Reset ("No Connection");
* REQUEST: perform Step 14 directly (no need to enqueue packet);
* RESPOND: dccp_check_req() will generate a Reset ("Packet Error") -- left it at that;
* OPEN/PARTOPEN: enter PASSIVE_CLOSE so that application has a chance to process unread data;
* CLOSEREQ: server performed active-close -- perform Step 14;
* CLOSING: simultaneous-close: use a tie-breaker to avoid message ping-pong (see comment);
* PASSIVE_CLOSEREQ: ignore - the peer has a bug (sending first a CloseReq and now a Close);
* TIMEWAIT: packet is ignored.
Note that the condition of receiving a packet in state CLOSED here is different from the condition "there
is no socket for such a connection": the socket still exists, but its state indicates it is unusable.
Last, dccp_finish_passive_close sets either DCCP_CLOSED or DCCP_CLOSING = TCP_CLOSING, so that
sk_stream_wait_close() will wait for the final Reset (which will trigger CLOSING => CLOSED).
Signed-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2007-11-28 16:59:48 +03:00
static int dccp_rcv_close ( struct sock * sk , struct sk_buff * skb )
2005-08-10 07:14:34 +04:00
{
[DCCP]: Integrate state transitions for passive-close
This adds the necessary state transitions for the two forms of passive-close
* PASSIVE_CLOSE - which is entered when a host receives a Close;
* PASSIVE_CLOSEREQ - which is entered when a client receives a CloseReq.
Here is a detailed account of what the patch does in each state.
1) Receiving CloseReq
The pseudo-code in 8.5 says:
Step 13: Process CloseReq
If P.type == CloseReq and S.state < CLOSEREQ,
Generate Close
S.state := CLOSING
Set CLOSING timer.
This means we need to address what to do in CLOSED, LISTEN, REQUEST, RESPOND, PARTOPEN, and OPEN.
* CLOSED: silently ignore - it may be a late or duplicate CloseReq;
* LISTEN/RESPOND: will not appear, since Step 7 is performed first (we know we are the client);
* REQUEST: perform Step 13 directly (no need to enqueue packet);
* OPEN/PARTOPEN: enter PASSIVE_CLOSEREQ so that the application has a chance to process unread data.
When already in PASSIVE_CLOSEREQ, no second CloseReq is enqueued. In any other state, the CloseReq is ignored.
I think that this offers some robustness against rare and pathological cases: e.g. a simultaneous close where
the client sends a Close and the server a CloseReq. The client will then be retransmitting its Close until it
gets the Reset, so ignoring the CloseReq while in state CLOSING is sane.
2) Receiving Close
The code below from 8.5 is unconditional.
Step 14: Process Close
If P.type == Close,
Generate Reset(Closed)
Tear down connection
Drop packet and return
Thus we need to consider all states:
* CLOSED: silently ignore, since this can happen when a retransmitted or late Close arrives;
* LISTEN: dccp_rcv_state_process() will generate a Reset ("No Connection");
* REQUEST: perform Step 14 directly (no need to enqueue packet);
* RESPOND: dccp_check_req() will generate a Reset ("Packet Error") -- left it at that;
* OPEN/PARTOPEN: enter PASSIVE_CLOSE so that application has a chance to process unread data;
* CLOSEREQ: server performed active-close -- perform Step 14;
* CLOSING: simultaneous-close: use a tie-breaker to avoid message ping-pong (see comment);
* PASSIVE_CLOSEREQ: ignore - the peer has a bug (sending first a CloseReq and now a Close);
* TIMEWAIT: packet is ignored.
Note that the condition of receiving a packet in state CLOSED here is different from the condition "there
is no socket for such a connection": the socket still exists, but its state indicates it is unusable.
Last, dccp_finish_passive_close sets either DCCP_CLOSED or DCCP_CLOSING = TCP_CLOSING, so that
sk_stream_wait_close() will wait for the final Reset (which will trigger CLOSING => CLOSED).
Signed-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2007-11-28 16:59:48 +03:00
int queued = 0 ;
switch ( sk - > sk_state ) {
/*
* We ignore Close when received in one of the following states :
* - CLOSED ( may be a late or duplicate packet )
* - PASSIVE_CLOSEREQ ( the peer has sent a CloseReq earlier )
* - RESPOND ( already handled by dccp_check_req )
*/
case DCCP_CLOSING :
/*
* Simultaneous - close : receiving a Close after sending one . This
* can happen if both client and server perform active - close and
* will result in an endless ping - pong of crossing and retrans -
* mitted Close packets , which only terminates when one of the
* nodes times out ( min . 64 seconds ) . Quicker convergence can be
* achieved when one of the nodes acts as tie - breaker .
* This is ok as both ends are done with data transfer and each
* end is just waiting for the other to acknowledge termination .
*/
if ( dccp_sk ( sk ) - > dccps_role ! = DCCP_ROLE_CLIENT )
break ;
2020-08-24 01:36:59 +03:00
fallthrough ;
[DCCP]: Integrate state transitions for passive-close
This adds the necessary state transitions for the two forms of passive-close
* PASSIVE_CLOSE - which is entered when a host receives a Close;
* PASSIVE_CLOSEREQ - which is entered when a client receives a CloseReq.
Here is a detailed account of what the patch does in each state.
1) Receiving CloseReq
The pseudo-code in 8.5 says:
Step 13: Process CloseReq
If P.type == CloseReq and S.state < CLOSEREQ,
Generate Close
S.state := CLOSING
Set CLOSING timer.
This means we need to address what to do in CLOSED, LISTEN, REQUEST, RESPOND, PARTOPEN, and OPEN.
* CLOSED: silently ignore - it may be a late or duplicate CloseReq;
* LISTEN/RESPOND: will not appear, since Step 7 is performed first (we know we are the client);
* REQUEST: perform Step 13 directly (no need to enqueue packet);
* OPEN/PARTOPEN: enter PASSIVE_CLOSEREQ so that the application has a chance to process unread data.
When already in PASSIVE_CLOSEREQ, no second CloseReq is enqueued. In any other state, the CloseReq is ignored.
I think that this offers some robustness against rare and pathological cases: e.g. a simultaneous close where
the client sends a Close and the server a CloseReq. The client will then be retransmitting its Close until it
gets the Reset, so ignoring the CloseReq while in state CLOSING is sane.
2) Receiving Close
The code below from 8.5 is unconditional.
Step 14: Process Close
If P.type == Close,
Generate Reset(Closed)
Tear down connection
Drop packet and return
Thus we need to consider all states:
* CLOSED: silently ignore, since this can happen when a retransmitted or late Close arrives;
* LISTEN: dccp_rcv_state_process() will generate a Reset ("No Connection");
* REQUEST: perform Step 14 directly (no need to enqueue packet);
* RESPOND: dccp_check_req() will generate a Reset ("Packet Error") -- left it at that;
* OPEN/PARTOPEN: enter PASSIVE_CLOSE so that application has a chance to process unread data;
* CLOSEREQ: server performed active-close -- perform Step 14;
* CLOSING: simultaneous-close: use a tie-breaker to avoid message ping-pong (see comment);
* PASSIVE_CLOSEREQ: ignore - the peer has a bug (sending first a CloseReq and now a Close);
* TIMEWAIT: packet is ignored.
Note that the condition of receiving a packet in state CLOSED here is different from the condition "there
is no socket for such a connection": the socket still exists, but its state indicates it is unusable.
Last, dccp_finish_passive_close sets either DCCP_CLOSED or DCCP_CLOSING = TCP_CLOSING, so that
sk_stream_wait_close() will wait for the final Reset (which will trigger CLOSING => CLOSED).
Signed-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2007-11-28 16:59:48 +03:00
case DCCP_REQUESTING :
case DCCP_ACTIVE_CLOSEREQ :
dccp_send_reset ( sk , DCCP_RESET_CODE_CLOSED ) ;
dccp_done ( sk ) ;
break ;
case DCCP_OPEN :
case DCCP_PARTOPEN :
/* Give waiting application a chance to read pending data */
queued = 1 ;
dccp_fin ( sk , skb ) ;
dccp_set_state ( sk , DCCP_PASSIVE_CLOSE ) ;
2020-08-24 01:36:59 +03:00
fallthrough ;
[DCCP]: Integrate state transitions for passive-close
This adds the necessary state transitions for the two forms of passive-close
* PASSIVE_CLOSE - which is entered when a host receives a Close;
* PASSIVE_CLOSEREQ - which is entered when a client receives a CloseReq.
Here is a detailed account of what the patch does in each state.
1) Receiving CloseReq
The pseudo-code in 8.5 says:
Step 13: Process CloseReq
If P.type == CloseReq and S.state < CLOSEREQ,
Generate Close
S.state := CLOSING
Set CLOSING timer.
This means we need to address what to do in CLOSED, LISTEN, REQUEST, RESPOND, PARTOPEN, and OPEN.
* CLOSED: silently ignore - it may be a late or duplicate CloseReq;
* LISTEN/RESPOND: will not appear, since Step 7 is performed first (we know we are the client);
* REQUEST: perform Step 13 directly (no need to enqueue packet);
* OPEN/PARTOPEN: enter PASSIVE_CLOSEREQ so that the application has a chance to process unread data.
When already in PASSIVE_CLOSEREQ, no second CloseReq is enqueued. In any other state, the CloseReq is ignored.
I think that this offers some robustness against rare and pathological cases: e.g. a simultaneous close where
the client sends a Close and the server a CloseReq. The client will then be retransmitting its Close until it
gets the Reset, so ignoring the CloseReq while in state CLOSING is sane.
2) Receiving Close
The code below from 8.5 is unconditional.
Step 14: Process Close
If P.type == Close,
Generate Reset(Closed)
Tear down connection
Drop packet and return
Thus we need to consider all states:
* CLOSED: silently ignore, since this can happen when a retransmitted or late Close arrives;
* LISTEN: dccp_rcv_state_process() will generate a Reset ("No Connection");
* REQUEST: perform Step 14 directly (no need to enqueue packet);
* RESPOND: dccp_check_req() will generate a Reset ("Packet Error") -- left it at that;
* OPEN/PARTOPEN: enter PASSIVE_CLOSE so that application has a chance to process unread data;
* CLOSEREQ: server performed active-close -- perform Step 14;
* CLOSING: simultaneous-close: use a tie-breaker to avoid message ping-pong (see comment);
* PASSIVE_CLOSEREQ: ignore - the peer has a bug (sending first a CloseReq and now a Close);
* TIMEWAIT: packet is ignored.
Note that the condition of receiving a packet in state CLOSED here is different from the condition "there
is no socket for such a connection": the socket still exists, but its state indicates it is unusable.
Last, dccp_finish_passive_close sets either DCCP_CLOSED or DCCP_CLOSING = TCP_CLOSING, so that
sk_stream_wait_close() will wait for the final Reset (which will trigger CLOSING => CLOSED).
Signed-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2007-11-28 16:59:48 +03:00
case DCCP_PASSIVE_CLOSE :
/*
* Retransmitted Close : we have already enqueued the first one .
*/
sk_wake_async ( sk , SOCK_WAKE_WAITD , POLL_HUP ) ;
}
return queued ;
2005-08-10 07:14:34 +04:00
}
[DCCP]: Integrate state transitions for passive-close
This adds the necessary state transitions for the two forms of passive-close
* PASSIVE_CLOSE - which is entered when a host receives a Close;
* PASSIVE_CLOSEREQ - which is entered when a client receives a CloseReq.
Here is a detailed account of what the patch does in each state.
1) Receiving CloseReq
The pseudo-code in 8.5 says:
Step 13: Process CloseReq
If P.type == CloseReq and S.state < CLOSEREQ,
Generate Close
S.state := CLOSING
Set CLOSING timer.
This means we need to address what to do in CLOSED, LISTEN, REQUEST, RESPOND, PARTOPEN, and OPEN.
* CLOSED: silently ignore - it may be a late or duplicate CloseReq;
* LISTEN/RESPOND: will not appear, since Step 7 is performed first (we know we are the client);
* REQUEST: perform Step 13 directly (no need to enqueue packet);
* OPEN/PARTOPEN: enter PASSIVE_CLOSEREQ so that the application has a chance to process unread data.
When already in PASSIVE_CLOSEREQ, no second CloseReq is enqueued. In any other state, the CloseReq is ignored.
I think that this offers some robustness against rare and pathological cases: e.g. a simultaneous close where
the client sends a Close and the server a CloseReq. The client will then be retransmitting its Close until it
gets the Reset, so ignoring the CloseReq while in state CLOSING is sane.
2) Receiving Close
The code below from 8.5 is unconditional.
Step 14: Process Close
If P.type == Close,
Generate Reset(Closed)
Tear down connection
Drop packet and return
Thus we need to consider all states:
* CLOSED: silently ignore, since this can happen when a retransmitted or late Close arrives;
* LISTEN: dccp_rcv_state_process() will generate a Reset ("No Connection");
* REQUEST: perform Step 14 directly (no need to enqueue packet);
* RESPOND: dccp_check_req() will generate a Reset ("Packet Error") -- left it at that;
* OPEN/PARTOPEN: enter PASSIVE_CLOSE so that application has a chance to process unread data;
* CLOSEREQ: server performed active-close -- perform Step 14;
* CLOSING: simultaneous-close: use a tie-breaker to avoid message ping-pong (see comment);
* PASSIVE_CLOSEREQ: ignore - the peer has a bug (sending first a CloseReq and now a Close);
* TIMEWAIT: packet is ignored.
Note that the condition of receiving a packet in state CLOSED here is different from the condition "there
is no socket for such a connection": the socket still exists, but its state indicates it is unusable.
Last, dccp_finish_passive_close sets either DCCP_CLOSED or DCCP_CLOSING = TCP_CLOSING, so that
sk_stream_wait_close() will wait for the final Reset (which will trigger CLOSING => CLOSED).
Signed-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2007-11-28 16:59:48 +03:00
static int dccp_rcv_closereq ( struct sock * sk , struct sk_buff * skb )
2005-08-10 07:14:34 +04:00
{
[DCCP]: Integrate state transitions for passive-close
This adds the necessary state transitions for the two forms of passive-close
* PASSIVE_CLOSE - which is entered when a host receives a Close;
* PASSIVE_CLOSEREQ - which is entered when a client receives a CloseReq.
Here is a detailed account of what the patch does in each state.
1) Receiving CloseReq
The pseudo-code in 8.5 says:
Step 13: Process CloseReq
If P.type == CloseReq and S.state < CLOSEREQ,
Generate Close
S.state := CLOSING
Set CLOSING timer.
This means we need to address what to do in CLOSED, LISTEN, REQUEST, RESPOND, PARTOPEN, and OPEN.
* CLOSED: silently ignore - it may be a late or duplicate CloseReq;
* LISTEN/RESPOND: will not appear, since Step 7 is performed first (we know we are the client);
* REQUEST: perform Step 13 directly (no need to enqueue packet);
* OPEN/PARTOPEN: enter PASSIVE_CLOSEREQ so that the application has a chance to process unread data.
When already in PASSIVE_CLOSEREQ, no second CloseReq is enqueued. In any other state, the CloseReq is ignored.
I think that this offers some robustness against rare and pathological cases: e.g. a simultaneous close where
the client sends a Close and the server a CloseReq. The client will then be retransmitting its Close until it
gets the Reset, so ignoring the CloseReq while in state CLOSING is sane.
2) Receiving Close
The code below from 8.5 is unconditional.
Step 14: Process Close
If P.type == Close,
Generate Reset(Closed)
Tear down connection
Drop packet and return
Thus we need to consider all states:
* CLOSED: silently ignore, since this can happen when a retransmitted or late Close arrives;
* LISTEN: dccp_rcv_state_process() will generate a Reset ("No Connection");
* REQUEST: perform Step 14 directly (no need to enqueue packet);
* RESPOND: dccp_check_req() will generate a Reset ("Packet Error") -- left it at that;
* OPEN/PARTOPEN: enter PASSIVE_CLOSE so that application has a chance to process unread data;
* CLOSEREQ: server performed active-close -- perform Step 14;
* CLOSING: simultaneous-close: use a tie-breaker to avoid message ping-pong (see comment);
* PASSIVE_CLOSEREQ: ignore - the peer has a bug (sending first a CloseReq and now a Close);
* TIMEWAIT: packet is ignored.
Note that the condition of receiving a packet in state CLOSED here is different from the condition "there
is no socket for such a connection": the socket still exists, but its state indicates it is unusable.
Last, dccp_finish_passive_close sets either DCCP_CLOSED or DCCP_CLOSING = TCP_CLOSING, so that
sk_stream_wait_close() will wait for the final Reset (which will trigger CLOSING => CLOSED).
Signed-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2007-11-28 16:59:48 +03:00
int queued = 0 ;
2005-08-10 07:14:34 +04:00
/*
* Step 7 : Check for unexpected packet types
* If ( S . is_server and P . type = = CloseReq )
* Send Sync packet acknowledging P . seqno
* Drop packet and return
*/
if ( dccp_sk ( sk ) - > dccps_role ! = DCCP_ROLE_CLIENT ) {
2005-08-17 10:10:59 +04:00
dccp_send_sync ( sk , DCCP_SKB_CB ( skb ) - > dccpd_seq , DCCP_PKT_SYNC ) ;
[DCCP]: Integrate state transitions for passive-close
This adds the necessary state transitions for the two forms of passive-close
* PASSIVE_CLOSE - which is entered when a host receives a Close;
* PASSIVE_CLOSEREQ - which is entered when a client receives a CloseReq.
Here is a detailed account of what the patch does in each state.
1) Receiving CloseReq
The pseudo-code in 8.5 says:
Step 13: Process CloseReq
If P.type == CloseReq and S.state < CLOSEREQ,
Generate Close
S.state := CLOSING
Set CLOSING timer.
This means we need to address what to do in CLOSED, LISTEN, REQUEST, RESPOND, PARTOPEN, and OPEN.
* CLOSED: silently ignore - it may be a late or duplicate CloseReq;
* LISTEN/RESPOND: will not appear, since Step 7 is performed first (we know we are the client);
* REQUEST: perform Step 13 directly (no need to enqueue packet);
* OPEN/PARTOPEN: enter PASSIVE_CLOSEREQ so that the application has a chance to process unread data.
When already in PASSIVE_CLOSEREQ, no second CloseReq is enqueued. In any other state, the CloseReq is ignored.
I think that this offers some robustness against rare and pathological cases: e.g. a simultaneous close where
the client sends a Close and the server a CloseReq. The client will then be retransmitting its Close until it
gets the Reset, so ignoring the CloseReq while in state CLOSING is sane.
2) Receiving Close
The code below from 8.5 is unconditional.
Step 14: Process Close
If P.type == Close,
Generate Reset(Closed)
Tear down connection
Drop packet and return
Thus we need to consider all states:
* CLOSED: silently ignore, since this can happen when a retransmitted or late Close arrives;
* LISTEN: dccp_rcv_state_process() will generate a Reset ("No Connection");
* REQUEST: perform Step 14 directly (no need to enqueue packet);
* RESPOND: dccp_check_req() will generate a Reset ("Packet Error") -- left it at that;
* OPEN/PARTOPEN: enter PASSIVE_CLOSE so that application has a chance to process unread data;
* CLOSEREQ: server performed active-close -- perform Step 14;
* CLOSING: simultaneous-close: use a tie-breaker to avoid message ping-pong (see comment);
* PASSIVE_CLOSEREQ: ignore - the peer has a bug (sending first a CloseReq and now a Close);
* TIMEWAIT: packet is ignored.
Note that the condition of receiving a packet in state CLOSED here is different from the condition "there
is no socket for such a connection": the socket still exists, but its state indicates it is unusable.
Last, dccp_finish_passive_close sets either DCCP_CLOSED or DCCP_CLOSING = TCP_CLOSING, so that
sk_stream_wait_close() will wait for the final Reset (which will trigger CLOSING => CLOSED).
Signed-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2007-11-28 16:59:48 +03:00
return queued ;
2005-08-10 07:14:34 +04:00
}
[DCCP]: Integrate state transitions for passive-close
This adds the necessary state transitions for the two forms of passive-close
* PASSIVE_CLOSE - which is entered when a host receives a Close;
* PASSIVE_CLOSEREQ - which is entered when a client receives a CloseReq.
Here is a detailed account of what the patch does in each state.
1) Receiving CloseReq
The pseudo-code in 8.5 says:
Step 13: Process CloseReq
If P.type == CloseReq and S.state < CLOSEREQ,
Generate Close
S.state := CLOSING
Set CLOSING timer.
This means we need to address what to do in CLOSED, LISTEN, REQUEST, RESPOND, PARTOPEN, and OPEN.
* CLOSED: silently ignore - it may be a late or duplicate CloseReq;
* LISTEN/RESPOND: will not appear, since Step 7 is performed first (we know we are the client);
* REQUEST: perform Step 13 directly (no need to enqueue packet);
* OPEN/PARTOPEN: enter PASSIVE_CLOSEREQ so that the application has a chance to process unread data.
When already in PASSIVE_CLOSEREQ, no second CloseReq is enqueued. In any other state, the CloseReq is ignored.
I think that this offers some robustness against rare and pathological cases: e.g. a simultaneous close where
the client sends a Close and the server a CloseReq. The client will then be retransmitting its Close until it
gets the Reset, so ignoring the CloseReq while in state CLOSING is sane.
2) Receiving Close
The code below from 8.5 is unconditional.
Step 14: Process Close
If P.type == Close,
Generate Reset(Closed)
Tear down connection
Drop packet and return
Thus we need to consider all states:
* CLOSED: silently ignore, since this can happen when a retransmitted or late Close arrives;
* LISTEN: dccp_rcv_state_process() will generate a Reset ("No Connection");
* REQUEST: perform Step 14 directly (no need to enqueue packet);
* RESPOND: dccp_check_req() will generate a Reset ("Packet Error") -- left it at that;
* OPEN/PARTOPEN: enter PASSIVE_CLOSE so that application has a chance to process unread data;
* CLOSEREQ: server performed active-close -- perform Step 14;
* CLOSING: simultaneous-close: use a tie-breaker to avoid message ping-pong (see comment);
* PASSIVE_CLOSEREQ: ignore - the peer has a bug (sending first a CloseReq and now a Close);
* TIMEWAIT: packet is ignored.
Note that the condition of receiving a packet in state CLOSED here is different from the condition "there
is no socket for such a connection": the socket still exists, but its state indicates it is unusable.
Last, dccp_finish_passive_close sets either DCCP_CLOSED or DCCP_CLOSING = TCP_CLOSING, so that
sk_stream_wait_close() will wait for the final Reset (which will trigger CLOSING => CLOSED).
Signed-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2007-11-28 16:59:48 +03:00
/* Step 13: process relevant Client states < CLOSEREQ */
switch ( sk - > sk_state ) {
case DCCP_REQUESTING :
dccp_send_close ( sk , 0 ) ;
2005-09-14 02:03:15 +04:00
dccp_set_state ( sk , DCCP_CLOSING ) ;
[DCCP]: Integrate state transitions for passive-close
This adds the necessary state transitions for the two forms of passive-close
* PASSIVE_CLOSE - which is entered when a host receives a Close;
* PASSIVE_CLOSEREQ - which is entered when a client receives a CloseReq.
Here is a detailed account of what the patch does in each state.
1) Receiving CloseReq
The pseudo-code in 8.5 says:
Step 13: Process CloseReq
If P.type == CloseReq and S.state < CLOSEREQ,
Generate Close
S.state := CLOSING
Set CLOSING timer.
This means we need to address what to do in CLOSED, LISTEN, REQUEST, RESPOND, PARTOPEN, and OPEN.
* CLOSED: silently ignore - it may be a late or duplicate CloseReq;
* LISTEN/RESPOND: will not appear, since Step 7 is performed first (we know we are the client);
* REQUEST: perform Step 13 directly (no need to enqueue packet);
* OPEN/PARTOPEN: enter PASSIVE_CLOSEREQ so that the application has a chance to process unread data.
When already in PASSIVE_CLOSEREQ, no second CloseReq is enqueued. In any other state, the CloseReq is ignored.
I think that this offers some robustness against rare and pathological cases: e.g. a simultaneous close where
the client sends a Close and the server a CloseReq. The client will then be retransmitting its Close until it
gets the Reset, so ignoring the CloseReq while in state CLOSING is sane.
2) Receiving Close
The code below from 8.5 is unconditional.
Step 14: Process Close
If P.type == Close,
Generate Reset(Closed)
Tear down connection
Drop packet and return
Thus we need to consider all states:
* CLOSED: silently ignore, since this can happen when a retransmitted or late Close arrives;
* LISTEN: dccp_rcv_state_process() will generate a Reset ("No Connection");
* REQUEST: perform Step 14 directly (no need to enqueue packet);
* RESPOND: dccp_check_req() will generate a Reset ("Packet Error") -- left it at that;
* OPEN/PARTOPEN: enter PASSIVE_CLOSE so that application has a chance to process unread data;
* CLOSEREQ: server performed active-close -- perform Step 14;
* CLOSING: simultaneous-close: use a tie-breaker to avoid message ping-pong (see comment);
* PASSIVE_CLOSEREQ: ignore - the peer has a bug (sending first a CloseReq and now a Close);
* TIMEWAIT: packet is ignored.
Note that the condition of receiving a packet in state CLOSED here is different from the condition "there
is no socket for such a connection": the socket still exists, but its state indicates it is unusable.
Last, dccp_finish_passive_close sets either DCCP_CLOSED or DCCP_CLOSING = TCP_CLOSING, so that
sk_stream_wait_close() will wait for the final Reset (which will trigger CLOSING => CLOSED).
Signed-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2007-11-28 16:59:48 +03:00
break ;
case DCCP_OPEN :
case DCCP_PARTOPEN :
/* Give waiting application a chance to read pending data */
queued = 1 ;
dccp_fin ( sk , skb ) ;
dccp_set_state ( sk , DCCP_PASSIVE_CLOSEREQ ) ;
2020-08-24 01:36:59 +03:00
fallthrough ;
[DCCP]: Integrate state transitions for passive-close
This adds the necessary state transitions for the two forms of passive-close
* PASSIVE_CLOSE - which is entered when a host receives a Close;
* PASSIVE_CLOSEREQ - which is entered when a client receives a CloseReq.
Here is a detailed account of what the patch does in each state.
1) Receiving CloseReq
The pseudo-code in 8.5 says:
Step 13: Process CloseReq
If P.type == CloseReq and S.state < CLOSEREQ,
Generate Close
S.state := CLOSING
Set CLOSING timer.
This means we need to address what to do in CLOSED, LISTEN, REQUEST, RESPOND, PARTOPEN, and OPEN.
* CLOSED: silently ignore - it may be a late or duplicate CloseReq;
* LISTEN/RESPOND: will not appear, since Step 7 is performed first (we know we are the client);
* REQUEST: perform Step 13 directly (no need to enqueue packet);
* OPEN/PARTOPEN: enter PASSIVE_CLOSEREQ so that the application has a chance to process unread data.
When already in PASSIVE_CLOSEREQ, no second CloseReq is enqueued. In any other state, the CloseReq is ignored.
I think that this offers some robustness against rare and pathological cases: e.g. a simultaneous close where
the client sends a Close and the server a CloseReq. The client will then be retransmitting its Close until it
gets the Reset, so ignoring the CloseReq while in state CLOSING is sane.
2) Receiving Close
The code below from 8.5 is unconditional.
Step 14: Process Close
If P.type == Close,
Generate Reset(Closed)
Tear down connection
Drop packet and return
Thus we need to consider all states:
* CLOSED: silently ignore, since this can happen when a retransmitted or late Close arrives;
* LISTEN: dccp_rcv_state_process() will generate a Reset ("No Connection");
* REQUEST: perform Step 14 directly (no need to enqueue packet);
* RESPOND: dccp_check_req() will generate a Reset ("Packet Error") -- left it at that;
* OPEN/PARTOPEN: enter PASSIVE_CLOSE so that application has a chance to process unread data;
* CLOSEREQ: server performed active-close -- perform Step 14;
* CLOSING: simultaneous-close: use a tie-breaker to avoid message ping-pong (see comment);
* PASSIVE_CLOSEREQ: ignore - the peer has a bug (sending first a CloseReq and now a Close);
* TIMEWAIT: packet is ignored.
Note that the condition of receiving a packet in state CLOSED here is different from the condition "there
is no socket for such a connection": the socket still exists, but its state indicates it is unusable.
Last, dccp_finish_passive_close sets either DCCP_CLOSED or DCCP_CLOSING = TCP_CLOSING, so that
sk_stream_wait_close() will wait for the final Reset (which will trigger CLOSING => CLOSED).
Signed-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2007-11-28 16:59:48 +03:00
case DCCP_PASSIVE_CLOSEREQ :
sk_wake_async ( sk , SOCK_WAKE_WAITD , POLL_HUP ) ;
}
return queued ;
2005-08-10 07:14:34 +04:00
}
2010-05-25 05:37:02 +04:00
static u16 dccp_reset_code_convert ( const u8 code )
[DCCP]: Convert Reset code into socket error number
This adds support for converting the 11 currently defined Reset codes into system
error numbers, which are stored in sk_err for further interpretation.
This makes the externally visible API behaviour similar to TCP, since a client
connecting to a non-existing port will experience ECONNREFUSED.
* Code 0, Unspecified, is interpreted as non-error (0);
* Code 1, Closed (normal termination), also maps into 0;
* Code 2, Aborted, maps into "Connection reset by peer" (ECONNRESET);
* Code 3, No Connection and
Code 7, Connection Refused, map into "Connection refused" (ECONNREFUSED);
* Code 4, Packet Error, maps into "No message of desired type" (ENOMSG);
* Code 5, Option Error, maps into "Illegal byte sequence" (EILSEQ);
* Code 6, Mandatory Error, maps into "Operation not supported on transport endpoint" (EOPNOTSUPP);
* Code 8, Bad Service Code, maps into "Invalid request code" (EBADRQC);
* Code 9, Too Busy, maps into "Too many users" (EUSERS);
* Code 10, Bad Init Cookie, maps into "Invalid request descriptor" (EBADR);
* Code 11, Aggression Penalty, maps into "Quota exceeded" (EDQUOT)
which makes sense in terms of using more than the `fair share' of bandwidth.
Signed-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>
Acked-by: Ian McDonald <ian.mcdonald@jandi.co.nz>
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2007-10-24 16:27:48 +04:00
{
2017-07-13 14:22:24 +03:00
static const u16 error_code [ ] = {
[DCCP]: Convert Reset code into socket error number
This adds support for converting the 11 currently defined Reset codes into system
error numbers, which are stored in sk_err for further interpretation.
This makes the externally visible API behaviour similar to TCP, since a client
connecting to a non-existing port will experience ECONNREFUSED.
* Code 0, Unspecified, is interpreted as non-error (0);
* Code 1, Closed (normal termination), also maps into 0;
* Code 2, Aborted, maps into "Connection reset by peer" (ECONNRESET);
* Code 3, No Connection and
Code 7, Connection Refused, map into "Connection refused" (ECONNREFUSED);
* Code 4, Packet Error, maps into "No message of desired type" (ENOMSG);
* Code 5, Option Error, maps into "Illegal byte sequence" (EILSEQ);
* Code 6, Mandatory Error, maps into "Operation not supported on transport endpoint" (EOPNOTSUPP);
* Code 8, Bad Service Code, maps into "Invalid request code" (EBADRQC);
* Code 9, Too Busy, maps into "Too many users" (EUSERS);
* Code 10, Bad Init Cookie, maps into "Invalid request descriptor" (EBADR);
* Code 11, Aggression Penalty, maps into "Quota exceeded" (EDQUOT)
which makes sense in terms of using more than the `fair share' of bandwidth.
Signed-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>
Acked-by: Ian McDonald <ian.mcdonald@jandi.co.nz>
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2007-10-24 16:27:48 +04:00
[ DCCP_RESET_CODE_CLOSED ] = 0 , /* normal termination */
[ DCCP_RESET_CODE_UNSPECIFIED ] = 0 , /* nothing known */
[ DCCP_RESET_CODE_ABORTED ] = ECONNRESET ,
[ DCCP_RESET_CODE_NO_CONNECTION ] = ECONNREFUSED ,
[ DCCP_RESET_CODE_CONNECTION_REFUSED ] = ECONNREFUSED ,
[ DCCP_RESET_CODE_TOO_BUSY ] = EUSERS ,
[ DCCP_RESET_CODE_AGGRESSION_PENALTY ] = EDQUOT ,
[ DCCP_RESET_CODE_PACKET_ERROR ] = ENOMSG ,
[ DCCP_RESET_CODE_BAD_INIT_COOKIE ] = EBADR ,
[ DCCP_RESET_CODE_BAD_SERVICE_CODE ] = EBADRQC ,
[ DCCP_RESET_CODE_OPTION_ERROR ] = EILSEQ ,
[ DCCP_RESET_CODE_MANDATORY_ERROR ] = EOPNOTSUPP ,
} ;
return code > = DCCP_MAX_RESET_CODES ? 0 : error_code [ code ] ;
}
static void dccp_rcv_reset ( struct sock * sk , struct sk_buff * skb )
{
2010-05-25 05:37:02 +04:00
u16 err = dccp_reset_code_convert ( dccp_hdr_reset ( skb ) - > dccph_reset_code ) ;
[DCCP]: Convert Reset code into socket error number
This adds support for converting the 11 currently defined Reset codes into system
error numbers, which are stored in sk_err for further interpretation.
This makes the externally visible API behaviour similar to TCP, since a client
connecting to a non-existing port will experience ECONNREFUSED.
* Code 0, Unspecified, is interpreted as non-error (0);
* Code 1, Closed (normal termination), also maps into 0;
* Code 2, Aborted, maps into "Connection reset by peer" (ECONNRESET);
* Code 3, No Connection and
Code 7, Connection Refused, map into "Connection refused" (ECONNREFUSED);
* Code 4, Packet Error, maps into "No message of desired type" (ENOMSG);
* Code 5, Option Error, maps into "Illegal byte sequence" (EILSEQ);
* Code 6, Mandatory Error, maps into "Operation not supported on transport endpoint" (EOPNOTSUPP);
* Code 8, Bad Service Code, maps into "Invalid request code" (EBADRQC);
* Code 9, Too Busy, maps into "Too many users" (EUSERS);
* Code 10, Bad Init Cookie, maps into "Invalid request descriptor" (EBADR);
* Code 11, Aggression Penalty, maps into "Quota exceeded" (EDQUOT)
which makes sense in terms of using more than the `fair share' of bandwidth.
Signed-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>
Acked-by: Ian McDonald <ian.mcdonald@jandi.co.nz>
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2007-10-24 16:27:48 +04:00
sk - > sk_err = err ;
/* Queue the equivalent of TCP fin so that dccp_recvmsg exits the loop */
dccp_fin ( sk , skb ) ;
if ( err & & ! sock_flag ( sk , SOCK_DEAD ) )
2007-11-26 15:10:50 +03:00
sk_wake_async ( sk , SOCK_WAKE_IO , POLL_ERR ) ;
[DCCP]: Convert Reset code into socket error number
This adds support for converting the 11 currently defined Reset codes into system
error numbers, which are stored in sk_err for further interpretation.
This makes the externally visible API behaviour similar to TCP, since a client
connecting to a non-existing port will experience ECONNREFUSED.
* Code 0, Unspecified, is interpreted as non-error (0);
* Code 1, Closed (normal termination), also maps into 0;
* Code 2, Aborted, maps into "Connection reset by peer" (ECONNRESET);
* Code 3, No Connection and
Code 7, Connection Refused, map into "Connection refused" (ECONNREFUSED);
* Code 4, Packet Error, maps into "No message of desired type" (ENOMSG);
* Code 5, Option Error, maps into "Illegal byte sequence" (EILSEQ);
* Code 6, Mandatory Error, maps into "Operation not supported on transport endpoint" (EOPNOTSUPP);
* Code 8, Bad Service Code, maps into "Invalid request code" (EBADRQC);
* Code 9, Too Busy, maps into "Too many users" (EUSERS);
* Code 10, Bad Init Cookie, maps into "Invalid request descriptor" (EBADR);
* Code 11, Aggression Penalty, maps into "Quota exceeded" (EDQUOT)
which makes sense in terms of using more than the `fair share' of bandwidth.
Signed-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>
Acked-by: Ian McDonald <ian.mcdonald@jandi.co.nz>
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2007-10-24 16:27:48 +04:00
dccp_time_wait ( sk , DCCP_TIME_WAIT , 0 ) ;
}
2010-11-14 19:25:36 +03:00
static void dccp_handle_ackvec_processing ( struct sock * sk , struct sk_buff * skb )
2005-08-10 07:14:34 +04:00
{
2010-11-14 19:25:36 +03:00
struct dccp_ackvec * av = dccp_sk ( sk ) - > dccps_hc_rx_ackvec ;
2005-08-10 07:14:34 +04:00
2010-11-14 19:25:36 +03:00
if ( av = = NULL )
return ;
if ( DCCP_SKB_CB ( skb ) - > dccpd_ack_seq ! = DCCP_PKT_WITHOUT_ACK_SEQ )
dccp_ackvec_clear_state ( av , DCCP_SKB_CB ( skb ) - > dccpd_ack_seq ) ;
dccp_ackvec_input ( av , skb ) ;
2005-08-10 07:14:34 +04:00
}
[DCCP]: Honour and make use of shutdown option set by user
This extends the DCCP socket API by honouring any shutdown(2) option set by the user.
The behaviour is, as much as possible, made consistent with the API for TCP's shutdown.
This patch exploits the information provided by the user via the socket API to reduce
processing costs:
* if the read end is closed (SHUT_RD), it is not necessary to deliver to input CCID;
* if the write end is closed (SHUT_WR), the same idea applies, but with a difference -
as long as the TX queue has not been drained, we need to receive feedback to keep
congestion-control rates up to date. Hence SHUT_WR is honoured only after the last
packet (under congestion control) has been sent;
* although SHUT_RDWR seems nonsensical, it is nevertheless supported in the same manner
as for TCP (and agrees with test for SHUTDOWN_MASK in dccp_poll() in net/dccp/proto.c).
Furthermore, most of the code already honours the sk_shutdown flags (dccp_recvmsg() for
instance sets the read length to 0 if SHUT_RD had been called); CCID handling is now added
to this by the present patch.
There will also no longer be any delivery when the socket is in the final stages, i.e. when
one of dccp_close(), dccp_fin(), or dccp_done() has been called - which is fine since at
that stage the connection is its final stages.
Motivation and background are on http://www.erg.abdn.ac.uk/users/gerrit/dccp/notes/shutdown
A FIXME has been added to notify the other end if SHUT_RD has been set (RFC 4340, 11.7).
Note: There is a comment in inet_shutdown() in net/ipv4/af_inet.c which asks to "make
sure the socket is a TCP socket". This should probably be extended to mean
`TCP or DCCP socket' (the code is also used by UDP and raw sockets).
Signed-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>
Signed-off-by: Ian McDonald <ian.mcdonald@jandi.co.nz>
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2007-11-21 14:56:48 +03:00
static void dccp_deliver_input_to_ccids ( struct sock * sk , struct sk_buff * skb )
{
const struct dccp_sock * dp = dccp_sk ( sk ) ;
/* Don't deliver to RX CCID when node has shut down read end. */
if ( ! ( sk - > sk_shutdown & RCV_SHUTDOWN ) )
ccid_hc_rx_packet_recv ( dp - > dccps_hc_rx_ccid , sk , skb ) ;
/*
* Until the TX queue has been drained , we can not honour SHUT_WR , since
* we need received feedback as input to adjust congestion control .
*/
if ( sk - > sk_write_queue . qlen > 0 | | ! ( sk - > sk_shutdown & SEND_SHUTDOWN ) )
ccid_hc_tx_packet_recv ( dp - > dccps_hc_tx_ccid , sk , skb ) ;
}
2005-08-10 07:14:34 +04:00
static int dccp_check_seqno ( struct sock * sk , struct sk_buff * skb )
{
const struct dccp_hdr * dh = dccp_hdr ( skb ) ;
struct dccp_sock * dp = dccp_sk ( sk ) ;
2007-09-26 09:41:19 +04:00
u64 lswl , lawl , seqno = DCCP_SKB_CB ( skb ) - > dccpd_seq ,
ackno = DCCP_SKB_CB ( skb ) - > dccpd_ack_seq ;
2005-08-10 07:14:34 +04:00
/*
* Step 5 : Prepare sequence numbers for Sync
* If P . type = = Sync or P . type = = SyncAck ,
* If S . AWL < = P . ackno < = S . AWH and P . seqno > = S . SWL ,
* / * P is valid , so update sequence number variables
* accordingly . After this update , P will pass the tests
* in Step 6. A SyncAck is generated if necessary in
* Step 15 * /
* Update S . GSR , S . SWL , S . SWH
* Otherwise ,
* Drop packet and return
*/
2006-12-10 21:01:18 +03:00
if ( dh - > dccph_type = = DCCP_PKT_SYNC | |
2005-08-10 07:14:34 +04:00
dh - > dccph_type = = DCCP_PKT_SYNCACK ) {
2007-09-26 09:41:19 +04:00
if ( between48 ( ackno , dp - > dccps_awl , dp - > dccps_awh ) & &
dccp_delta_seqno ( dp - > dccps_swl , seqno ) > = 0 )
dccp_update_gsr ( sk , seqno ) ;
2005-08-10 07:14:34 +04:00
else
return - 1 ;
2005-08-17 10:10:59 +04:00
}
2007-02-09 17:24:38 +03:00
2005-08-10 07:14:34 +04:00
/*
* Step 6 : Check sequence numbers
* Let LSWL = S . SWL and LAWL = S . AWL
* If P . type = = CloseReq or P . type = = Close or P . type = = Reset ,
* LSWL : = S . GSR + 1 , LAWL : = S . GAR
* If LSWL < = P . seqno < = S . SWH
* and ( P . ackno does not exist or LAWL < = P . ackno < = S . AWH ) ,
* Update S . GSR , S . SWL , S . SWH
* If P . type ! = Sync ,
* Update S . GAR
*/
2005-08-17 10:10:59 +04:00
lswl = dp - > dccps_swl ;
lawl = dp - > dccps_awl ;
if ( dh - > dccph_type = = DCCP_PKT_CLOSEREQ | |
2005-08-19 04:12:02 +04:00
dh - > dccph_type = = DCCP_PKT_CLOSE | |
dh - > dccph_type = = DCCP_PKT_RESET ) {
2007-09-26 09:41:19 +04:00
lswl = ADD48 ( dp - > dccps_gsr , 1 ) ;
2005-08-10 07:14:34 +04:00
lawl = dp - > dccps_gar ;
}
2007-09-26 09:41:19 +04:00
if ( between48 ( seqno , lswl , dp - > dccps_swh ) & &
( ackno = = DCCP_PKT_WITHOUT_ACK_SEQ | |
between48 ( ackno , lawl , dp - > dccps_awh ) ) ) {
dccp_update_gsr ( sk , seqno ) ;
2005-08-10 07:14:34 +04:00
if ( dh - > dccph_type ! = DCCP_PKT_SYNC & &
2010-11-23 05:36:56 +03:00
ackno ! = DCCP_PKT_WITHOUT_ACK_SEQ & &
after48 ( ackno , dp - > dccps_gar ) )
2007-09-26 09:41:19 +04:00
dp - > dccps_gar = ackno ;
2005-08-10 07:14:34 +04:00
} else {
2007-09-26 18:31:49 +04:00
unsigned long now = jiffies ;
/*
* Step 6 : Check sequence numbers
* Otherwise ,
* If P . type = = Reset ,
* Send Sync packet acknowledging S . GSR
* Otherwise ,
* Send Sync packet acknowledging P . seqno
* Drop packet and return
*
* These Syncs are rate - limited as per RFC 4340 , 7.5 .4 :
* at most 1 / ( dccp_sync_rate_limit * HZ ) Syncs per second .
*/
if ( time_before ( now , ( dp - > dccps_rate_last +
sysctl_dccp_sync_ratelimit ) ) )
2010-12-30 14:15:16 +03:00
return - 1 ;
2007-09-26 18:31:49 +04:00
2010-10-11 22:44:42 +04:00
DCCP_WARN ( " Step 6 failed for %s packet, "
2006-11-20 23:39:23 +03:00
" (LSWL(%llu) <= P.seqno(%llu) <= S.SWH(%llu)) and "
" (P.ackno %s or LAWL(%llu) <= P.ackno(%llu) <= S.AWH(%llu), "
" sending SYNC... \n " , dccp_packet_name ( dh - > dccph_type ) ,
2007-09-26 09:41:19 +04:00
( unsigned long long ) lswl , ( unsigned long long ) seqno ,
2006-11-20 23:39:23 +03:00
( unsigned long long ) dp - > dccps_swh ,
2007-09-26 09:41:19 +04:00
( ackno = = DCCP_PKT_WITHOUT_ACK_SEQ ) ? " doesn't exist "
: " exists " ,
( unsigned long long ) lawl , ( unsigned long long ) ackno ,
2006-11-20 23:39:23 +03:00
( unsigned long long ) dp - > dccps_awh ) ;
2007-09-26 18:31:49 +04:00
dp - > dccps_rate_last = now ;
2007-09-26 09:41:56 +04:00
if ( dh - > dccph_type = = DCCP_PKT_RESET )
seqno = dp - > dccps_gsr ;
2007-09-26 09:41:19 +04:00
dccp_send_sync ( sk , seqno , DCCP_PKT_SYNC ) ;
2005-08-10 07:14:34 +04:00
return - 1 ;
}
return 0 ;
}
2006-03-21 08:58:56 +03:00
static int __dccp_rcv_established ( struct sock * sk , struct sk_buff * skb ,
2012-04-15 09:58:06 +04:00
const struct dccp_hdr * dh , const unsigned int len )
2005-08-10 07:14:34 +04:00
{
struct dccp_sock * dp = dccp_sk ( sk ) ;
switch ( dccp_hdr ( skb ) - > dccph_type ) {
case DCCP_PKT_DATAACK :
case DCCP_PKT_DATA :
/*
[DCCP]: Honour and make use of shutdown option set by user
This extends the DCCP socket API by honouring any shutdown(2) option set by the user.
The behaviour is, as much as possible, made consistent with the API for TCP's shutdown.
This patch exploits the information provided by the user via the socket API to reduce
processing costs:
* if the read end is closed (SHUT_RD), it is not necessary to deliver to input CCID;
* if the write end is closed (SHUT_WR), the same idea applies, but with a difference -
as long as the TX queue has not been drained, we need to receive feedback to keep
congestion-control rates up to date. Hence SHUT_WR is honoured only after the last
packet (under congestion control) has been sent;
* although SHUT_RDWR seems nonsensical, it is nevertheless supported in the same manner
as for TCP (and agrees with test for SHUTDOWN_MASK in dccp_poll() in net/dccp/proto.c).
Furthermore, most of the code already honours the sk_shutdown flags (dccp_recvmsg() for
instance sets the read length to 0 if SHUT_RD had been called); CCID handling is now added
to this by the present patch.
There will also no longer be any delivery when the socket is in the final stages, i.e. when
one of dccp_close(), dccp_fin(), or dccp_done() has been called - which is fine since at
that stage the connection is its final stages.
Motivation and background are on http://www.erg.abdn.ac.uk/users/gerrit/dccp/notes/shutdown
A FIXME has been added to notify the other end if SHUT_RD has been set (RFC 4340, 11.7).
Note: There is a comment in inet_shutdown() in net/ipv4/af_inet.c which asks to "make
sure the socket is a TCP socket". This should probably be extended to mean
`TCP or DCCP socket' (the code is also used by UDP and raw sockets).
Signed-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>
Signed-off-by: Ian McDonald <ian.mcdonald@jandi.co.nz>
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2007-11-21 14:56:48 +03:00
* FIXME : schedule DATA_DROPPED ( RFC 4340 , 11.7 .2 ) if and when
* - sk_shutdown = = RCV_SHUTDOWN , use Code 1 , " Not Listening "
* - sk_receive_queue is full , use Code 2 , " Receive Buffer "
2005-08-10 07:14:34 +04:00
*/
2007-12-13 16:28:43 +03:00
dccp_enqueue_skb ( sk , skb ) ;
2005-08-10 07:14:34 +04:00
return 0 ;
case DCCP_PKT_ACK :
goto discard ;
case DCCP_PKT_RESET :
/*
* Step 9 : Process Reset
* If P . type = = Reset ,
* Tear down connection
* S . state : = TIMEWAIT
* Set TIMEWAIT timer
* Drop packet and return
[DCCP]: Convert Reset code into socket error number
This adds support for converting the 11 currently defined Reset codes into system
error numbers, which are stored in sk_err for further interpretation.
This makes the externally visible API behaviour similar to TCP, since a client
connecting to a non-existing port will experience ECONNREFUSED.
* Code 0, Unspecified, is interpreted as non-error (0);
* Code 1, Closed (normal termination), also maps into 0;
* Code 2, Aborted, maps into "Connection reset by peer" (ECONNRESET);
* Code 3, No Connection and
Code 7, Connection Refused, map into "Connection refused" (ECONNREFUSED);
* Code 4, Packet Error, maps into "No message of desired type" (ENOMSG);
* Code 5, Option Error, maps into "Illegal byte sequence" (EILSEQ);
* Code 6, Mandatory Error, maps into "Operation not supported on transport endpoint" (EOPNOTSUPP);
* Code 8, Bad Service Code, maps into "Invalid request code" (EBADRQC);
* Code 9, Too Busy, maps into "Too many users" (EUSERS);
* Code 10, Bad Init Cookie, maps into "Invalid request descriptor" (EBADR);
* Code 11, Aggression Penalty, maps into "Quota exceeded" (EDQUOT)
which makes sense in terms of using more than the `fair share' of bandwidth.
Signed-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>
Acked-by: Ian McDonald <ian.mcdonald@jandi.co.nz>
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2007-10-24 16:27:48 +04:00
*/
dccp_rcv_reset ( sk , skb ) ;
2005-08-10 07:14:34 +04:00
return 0 ;
case DCCP_PKT_CLOSEREQ :
[DCCP]: Integrate state transitions for passive-close
This adds the necessary state transitions for the two forms of passive-close
* PASSIVE_CLOSE - which is entered when a host receives a Close;
* PASSIVE_CLOSEREQ - which is entered when a client receives a CloseReq.
Here is a detailed account of what the patch does in each state.
1) Receiving CloseReq
The pseudo-code in 8.5 says:
Step 13: Process CloseReq
If P.type == CloseReq and S.state < CLOSEREQ,
Generate Close
S.state := CLOSING
Set CLOSING timer.
This means we need to address what to do in CLOSED, LISTEN, REQUEST, RESPOND, PARTOPEN, and OPEN.
* CLOSED: silently ignore - it may be a late or duplicate CloseReq;
* LISTEN/RESPOND: will not appear, since Step 7 is performed first (we know we are the client);
* REQUEST: perform Step 13 directly (no need to enqueue packet);
* OPEN/PARTOPEN: enter PASSIVE_CLOSEREQ so that the application has a chance to process unread data.
When already in PASSIVE_CLOSEREQ, no second CloseReq is enqueued. In any other state, the CloseReq is ignored.
I think that this offers some robustness against rare and pathological cases: e.g. a simultaneous close where
the client sends a Close and the server a CloseReq. The client will then be retransmitting its Close until it
gets the Reset, so ignoring the CloseReq while in state CLOSING is sane.
2) Receiving Close
The code below from 8.5 is unconditional.
Step 14: Process Close
If P.type == Close,
Generate Reset(Closed)
Tear down connection
Drop packet and return
Thus we need to consider all states:
* CLOSED: silently ignore, since this can happen when a retransmitted or late Close arrives;
* LISTEN: dccp_rcv_state_process() will generate a Reset ("No Connection");
* REQUEST: perform Step 14 directly (no need to enqueue packet);
* RESPOND: dccp_check_req() will generate a Reset ("Packet Error") -- left it at that;
* OPEN/PARTOPEN: enter PASSIVE_CLOSE so that application has a chance to process unread data;
* CLOSEREQ: server performed active-close -- perform Step 14;
* CLOSING: simultaneous-close: use a tie-breaker to avoid message ping-pong (see comment);
* PASSIVE_CLOSEREQ: ignore - the peer has a bug (sending first a CloseReq and now a Close);
* TIMEWAIT: packet is ignored.
Note that the condition of receiving a packet in state CLOSED here is different from the condition "there
is no socket for such a connection": the socket still exists, but its state indicates it is unusable.
Last, dccp_finish_passive_close sets either DCCP_CLOSED or DCCP_CLOSING = TCP_CLOSING, so that
sk_stream_wait_close() will wait for the final Reset (which will trigger CLOSING => CLOSED).
Signed-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2007-11-28 16:59:48 +03:00
if ( dccp_rcv_closereq ( sk , skb ) )
return 0 ;
2005-08-10 07:14:34 +04:00
goto discard ;
case DCCP_PKT_CLOSE :
[DCCP]: Integrate state transitions for passive-close
This adds the necessary state transitions for the two forms of passive-close
* PASSIVE_CLOSE - which is entered when a host receives a Close;
* PASSIVE_CLOSEREQ - which is entered when a client receives a CloseReq.
Here is a detailed account of what the patch does in each state.
1) Receiving CloseReq
The pseudo-code in 8.5 says:
Step 13: Process CloseReq
If P.type == CloseReq and S.state < CLOSEREQ,
Generate Close
S.state := CLOSING
Set CLOSING timer.
This means we need to address what to do in CLOSED, LISTEN, REQUEST, RESPOND, PARTOPEN, and OPEN.
* CLOSED: silently ignore - it may be a late or duplicate CloseReq;
* LISTEN/RESPOND: will not appear, since Step 7 is performed first (we know we are the client);
* REQUEST: perform Step 13 directly (no need to enqueue packet);
* OPEN/PARTOPEN: enter PASSIVE_CLOSEREQ so that the application has a chance to process unread data.
When already in PASSIVE_CLOSEREQ, no second CloseReq is enqueued. In any other state, the CloseReq is ignored.
I think that this offers some robustness against rare and pathological cases: e.g. a simultaneous close where
the client sends a Close and the server a CloseReq. The client will then be retransmitting its Close until it
gets the Reset, so ignoring the CloseReq while in state CLOSING is sane.
2) Receiving Close
The code below from 8.5 is unconditional.
Step 14: Process Close
If P.type == Close,
Generate Reset(Closed)
Tear down connection
Drop packet and return
Thus we need to consider all states:
* CLOSED: silently ignore, since this can happen when a retransmitted or late Close arrives;
* LISTEN: dccp_rcv_state_process() will generate a Reset ("No Connection");
* REQUEST: perform Step 14 directly (no need to enqueue packet);
* RESPOND: dccp_check_req() will generate a Reset ("Packet Error") -- left it at that;
* OPEN/PARTOPEN: enter PASSIVE_CLOSE so that application has a chance to process unread data;
* CLOSEREQ: server performed active-close -- perform Step 14;
* CLOSING: simultaneous-close: use a tie-breaker to avoid message ping-pong (see comment);
* PASSIVE_CLOSEREQ: ignore - the peer has a bug (sending first a CloseReq and now a Close);
* TIMEWAIT: packet is ignored.
Note that the condition of receiving a packet in state CLOSED here is different from the condition "there
is no socket for such a connection": the socket still exists, but its state indicates it is unusable.
Last, dccp_finish_passive_close sets either DCCP_CLOSED or DCCP_CLOSING = TCP_CLOSING, so that
sk_stream_wait_close() will wait for the final Reset (which will trigger CLOSING => CLOSED).
Signed-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2007-11-28 16:59:48 +03:00
if ( dccp_rcv_close ( sk , skb ) )
return 0 ;
goto discard ;
2005-08-10 07:14:34 +04:00
case DCCP_PKT_REQUEST :
2006-12-10 21:01:18 +03:00
/* Step 7
* or ( S . is_server and P . type = = Response )
2005-08-10 07:14:34 +04:00
* or ( S . is_client and P . type = = Request )
* or ( S . state > = OPEN and P . type = = Request
* and P . seqno > = S . OSR )
* or ( S . state > = OPEN and P . type = = Response
* and P . seqno > = S . OSR )
* or ( S . state = = RESPOND and P . type = = Data ) ,
* Send Sync packet acknowledging P . seqno
* Drop packet and return
*/
if ( dp - > dccps_role ! = DCCP_ROLE_LISTEN )
goto send_sync ;
goto check_seq ;
case DCCP_PKT_RESPONSE :
if ( dp - > dccps_role ! = DCCP_ROLE_CLIENT )
goto send_sync ;
check_seq :
2007-03-20 19:08:19 +03:00
if ( dccp_delta_seqno ( dp - > dccps_osr ,
DCCP_SKB_CB ( skb ) - > dccpd_seq ) > = 0 ) {
2005-08-10 07:14:34 +04:00
send_sync :
2005-08-17 10:10:59 +04:00
dccp_send_sync ( sk , DCCP_SKB_CB ( skb ) - > dccpd_seq ,
DCCP_PKT_SYNC ) ;
2005-08-10 07:14:34 +04:00
}
break ;
2005-08-17 10:10:59 +04:00
case DCCP_PKT_SYNC :
dccp_send_sync ( sk , DCCP_SKB_CB ( skb ) - > dccpd_seq ,
DCCP_PKT_SYNCACK ) ;
/*
2006-10-25 03:17:51 +04:00
* From RFC 4340 , sec . 5.7
2005-08-17 10:10:59 +04:00
*
* As with DCCP - Ack packets , DCCP - Sync and DCCP - SyncAck packets
* MAY have non - zero - length application data areas , whose
2006-10-25 03:17:51 +04:00
* contents receivers MUST ignore .
2005-08-17 10:10:59 +04:00
*/
goto discard ;
2005-08-10 07:14:34 +04:00
}
2016-04-30 00:16:49 +03:00
DCCP_INC_STATS ( DCCP_MIB_INERRS ) ;
2005-08-10 07:14:34 +04:00
discard :
__kfree_skb ( skb ) ;
return 0 ;
}
2006-01-04 01:25:17 +03:00
int dccp_rcv_established ( struct sock * sk , struct sk_buff * skb ,
2012-04-15 09:58:06 +04:00
const struct dccp_hdr * dh , const unsigned int len )
2006-01-04 01:25:17 +03:00
{
if ( dccp_check_seqno ( sk , skb ) )
goto discard ;
2007-12-13 17:29:24 +03:00
if ( dccp_parse_options ( sk , NULL , skb ) )
2008-08-23 15:28:27 +04:00
return 1 ;
2006-01-04 01:25:17 +03:00
2010-11-14 19:25:36 +03:00
dccp_handle_ackvec_processing ( sk , skb ) ;
[DCCP]: Honour and make use of shutdown option set by user
This extends the DCCP socket API by honouring any shutdown(2) option set by the user.
The behaviour is, as much as possible, made consistent with the API for TCP's shutdown.
This patch exploits the information provided by the user via the socket API to reduce
processing costs:
* if the read end is closed (SHUT_RD), it is not necessary to deliver to input CCID;
* if the write end is closed (SHUT_WR), the same idea applies, but with a difference -
as long as the TX queue has not been drained, we need to receive feedback to keep
congestion-control rates up to date. Hence SHUT_WR is honoured only after the last
packet (under congestion control) has been sent;
* although SHUT_RDWR seems nonsensical, it is nevertheless supported in the same manner
as for TCP (and agrees with test for SHUTDOWN_MASK in dccp_poll() in net/dccp/proto.c).
Furthermore, most of the code already honours the sk_shutdown flags (dccp_recvmsg() for
instance sets the read length to 0 if SHUT_RD had been called); CCID handling is now added
to this by the present patch.
There will also no longer be any delivery when the socket is in the final stages, i.e. when
one of dccp_close(), dccp_fin(), or dccp_done() has been called - which is fine since at
that stage the connection is its final stages.
Motivation and background are on http://www.erg.abdn.ac.uk/users/gerrit/dccp/notes/shutdown
A FIXME has been added to notify the other end if SHUT_RD has been set (RFC 4340, 11.7).
Note: There is a comment in inet_shutdown() in net/ipv4/af_inet.c which asks to "make
sure the socket is a TCP socket". This should probably be extended to mean
`TCP or DCCP socket' (the code is also used by UDP and raw sockets).
Signed-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>
Signed-off-by: Ian McDonald <ian.mcdonald@jandi.co.nz>
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2007-11-21 14:56:48 +03:00
dccp_deliver_input_to_ccids ( sk , skb ) ;
2006-01-04 01:25:17 +03:00
return __dccp_rcv_established ( sk , skb , dh , len ) ;
discard :
__kfree_skb ( skb ) ;
return 0 ;
}
2005-12-14 10:24:16 +03:00
EXPORT_SYMBOL_GPL ( dccp_rcv_established ) ;
2005-08-10 07:14:34 +04:00
static int dccp_rcv_request_sent_state_process ( struct sock * sk ,
struct sk_buff * skb ,
const struct dccp_hdr * dh ,
2012-04-15 09:58:06 +04:00
const unsigned int len )
2005-08-10 07:14:34 +04:00
{
2006-12-10 21:01:18 +03:00
/*
2005-08-10 07:14:34 +04:00
* Step 4 : Prepare sequence numbers in REQUEST
* If S . state = = REQUEST ,
* If ( P . type = = Response or P . type = = Reset )
* and S . AWL < = P . ackno < = S . AWH ,
* / * Set sequence number variables corresponding to the
* other endpoint , so P will pass the tests in Step 6 * /
* Set S . GSR , S . ISR , S . SWL , S . SWH
* / * Response processing continues in Step 10 ; Reset
* processing continues in Step 9 * /
*/
if ( dh - > dccph_type = = DCCP_PKT_RESPONSE ) {
const struct inet_connection_sock * icsk = inet_csk ( sk ) ;
struct dccp_sock * dp = dccp_sk ( sk ) ;
2007-09-26 09:40:44 +04:00
long tstamp = dccp_timestamp ( ) ;
2005-08-10 07:14:34 +04:00
2005-08-14 03:34:54 +04:00
if ( ! between48 ( DCCP_SKB_CB ( skb ) - > dccpd_ack_seq ,
dp - > dccps_awl , dp - > dccps_awh ) ) {
dccp_pr_debug ( " invalid ackno: S.AWL=%llu, "
2010-03-24 10:57:28 +03:00
" P.ackno=%llu, S.AWH=%llu \n " ,
2005-08-14 03:34:54 +04:00
( unsigned long long ) dp - > dccps_awl ,
( unsigned long long ) DCCP_SKB_CB ( skb ) - > dccpd_ack_seq ,
( unsigned long long ) dp - > dccps_awh ) ;
2005-08-10 07:14:34 +04:00
goto out_invalid_packet ;
}
2006-01-04 01:25:49 +03:00
2008-12-08 12:16:27 +03:00
/*
* If option processing ( Step 8 ) failed , return 1 here so that
* dccp_v4_do_rcv ( ) sends a Reset . The Reset code depends on
* the option type and is set in dccp_parse_options ( ) .
*/
2007-12-13 17:29:24 +03:00
if ( dccp_parse_options ( sk , NULL , skb ) )
2008-12-08 12:16:27 +03:00
return 1 ;
[DCCP]: Initial feature negotiation implementation
Still needs more work, but boots and doesn't crashes, even
does some negotiation!
18:38:52.174934 127.0.0.1.43458 > 127.0.0.1.5001: request <change_l ack_ratio 2, change_r ccid 2, change_l ccid 2>
18:38:52.218526 127.0.0.1.5001 > 127.0.0.1.43458: response <nop, nop, change_l ack_ratio 2, confirm_r ccid 2 2, confirm_l ccid 2 2, confirm_r ack_ratio 2>
18:38:52.185398 127.0.0.1.43458 > 127.0.0.1.5001: <nop, confirm_r ack_ratio 2, ack_vector0 0x00, elapsed_time 212>
:-)
Signed-off-by: Andrea Bittau <a.bittau@cs.ucl.ac.uk>
Signed-off-by: Arnaldo Carvalho de Melo <acme@mandriva.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2006-03-21 04:43:56 +03:00
2010-06-22 05:14:35 +04:00
/* Obtain usec RTT sample from SYN exchange (used by TFRC). */
2007-09-26 09:40:44 +04:00
if ( likely ( dp - > dccps_options_received . dccpor_timestamp_echo ) )
dp - > dccps_syn_rtt = dccp_sample_rtt ( sk , 10 * ( tstamp -
dp - > dccps_options_received . dccpor_timestamp_echo ) ) ;
2007-03-20 21:27:17 +03:00
2008-08-19 08:14:20 +04:00
/* Stop the REQUEST timer */
inet_csk_clear_xmit_timer ( sk , ICSK_TIME_RETRANS ) ;
WARN_ON ( sk - > sk_send_head = = NULL ) ;
kfree_skb ( sk - > sk_send_head ) ;
sk - > sk_send_head = NULL ;
2005-08-21 12:36:45 +04:00
/*
2010-10-11 22:35:40 +04:00
* Set ISR , GSR from packet . ISS was set in dccp_v { 4 , 6 } _connect
* and GSS in dccp_transmit_skb ( ) . Setting AWL / AWH and SWL / SWH
* is done as part of activating the feature values below , since
* these settings depend on the local / remote Sequence Window
* features , which were undefined or not confirmed until now .
2005-08-21 12:36:45 +04:00
*/
2010-10-11 22:35:40 +04:00
dp - > dccps_gsr = dp - > dccps_isr = DCCP_SKB_CB ( skb ) - > dccpd_seq ;
2005-08-10 07:14:34 +04:00
2005-12-14 10:26:10 +03:00
dccp_sync_mss ( sk , icsk - > icsk_pmtu_cookie ) ;
2005-08-10 07:14:34 +04:00
/*
* Step 10 : Process REQUEST state ( second part )
* If S . state = = REQUEST ,
2005-08-14 03:34:54 +04:00
* / * If we get here , P is a valid Response from the
* server ( see Step 4 ) , and we should move to
* PARTOPEN state . PARTOPEN means send an Ack ,
* don ' t send Data packets , retransmit Acks
* periodically , and always include any Init Cookie
* from the Response * /
2005-08-10 07:14:34 +04:00
* S . state : = PARTOPEN
* Set PARTOPEN timer
2006-12-10 21:01:18 +03:00
* Continue with S . state = = PARTOPEN
2005-08-14 03:34:54 +04:00
* / * Step 12 will send the Ack completing the
* three - way handshake * /
2005-08-10 07:14:34 +04:00
*/
dccp_set_state ( sk , DCCP_PARTOPEN ) ;
2008-12-08 12:16:27 +03:00
/*
* If feature negotiation was successful , activate features now ;
* an activation failure means that this host could not activate
* one ore more features ( e . g . insufficient memory ) , which would
* leave at least one feature in an undefined state .
*/
if ( dccp_feat_activate_values ( sk , & dp - > dccps_featneg ) )
goto unable_to_proceed ;
2005-08-10 07:14:34 +04:00
/* Make sure socket is routed, for correct metrics. */
2005-12-14 10:16:16 +03:00
icsk - > icsk_af_ops - > rebuild_header ( sk ) ;
2005-08-10 07:14:34 +04:00
if ( ! sock_flag ( sk , SOCK_DEAD ) ) {
sk - > sk_state_change ( sk ) ;
2007-11-26 15:10:50 +03:00
sk_wake_async ( sk , SOCK_WAKE_IO , POLL_OUT ) ;
2005-08-10 07:14:34 +04:00
}
2019-01-25 21:53:19 +03:00
if ( sk - > sk_write_pending | | inet_csk_in_pingpong_mode ( sk ) | |
2005-08-10 07:14:34 +04:00
icsk - > icsk_accept_queue . rskq_defer_accept ) {
/* Save one ACK. Data will be ready after
* several ticks , if write_pending is set .
*
* It may be deleted , but with this feature tcpdumps
* look so _wonderfully_ clever , that I was not able
* to stand against the temptation 8 ) - - ANK
*/
/*
* OK , in DCCP we can as well do a similar trick , its
* even in the draft , but there is no need for us to
* schedule an ack here , as dccp_sendmsg does this for
* us , also stated in the draft . - acme
*/
__kfree_skb ( skb ) ;
return 0 ;
2006-12-10 21:01:18 +03:00
}
2005-08-10 07:14:34 +04:00
dccp_send_ack ( sk ) ;
return - 1 ;
}
out_invalid_packet :
2005-09-17 03:58:33 +04:00
/* dccp_v4_do_rcv will send a reset */
DCCP_SKB_CB ( skb ) - > dccpd_reset_code = DCCP_RESET_CODE_PACKET_ERROR ;
2006-12-10 21:01:18 +03:00
return 1 ;
2008-12-08 12:16:27 +03:00
unable_to_proceed :
DCCP_SKB_CB ( skb ) - > dccpd_reset_code = DCCP_RESET_CODE_ABORTED ;
/*
* We mark this socket as no longer usable , so that the loop in
* dccp_sendmsg ( ) terminates and the application gets notified .
*/
dccp_set_state ( sk , DCCP_CLOSED ) ;
sk - > sk_err = ECOMM ;
return 1 ;
2005-08-10 07:14:34 +04:00
}
static int dccp_rcv_respond_partopen_state_process ( struct sock * sk ,
struct sk_buff * skb ,
const struct dccp_hdr * dh ,
2012-04-15 09:58:06 +04:00
const unsigned int len )
2005-08-10 07:14:34 +04:00
{
2010-06-22 05:14:35 +04:00
struct dccp_sock * dp = dccp_sk ( sk ) ;
u32 sample = dp - > dccps_options_received . dccpor_timestamp_echo ;
2005-08-10 07:14:34 +04:00
int queued = 0 ;
switch ( dh - > dccph_type ) {
case DCCP_PKT_RESET :
inet_csk_clear_xmit_timer ( sk , ICSK_TIME_DACK ) ;
break ;
2005-10-11 08:25:00 +04:00
case DCCP_PKT_DATA :
if ( sk - > sk_state = = DCCP_RESPOND )
break ;
2020-08-24 01:36:59 +03:00
fallthrough ;
2005-08-10 07:14:34 +04:00
case DCCP_PKT_DATAACK :
case DCCP_PKT_ACK :
/*
2014-11-18 00:00:22 +03:00
* FIXME : we should be resetting the PARTOPEN ( DELACK ) timer
2005-08-14 03:34:54 +04:00
* here but only if we haven ' t used the DELACK timer for
* something else , like sending a delayed ack for a TIMESTAMP
* echo , etc , for now were not clearing it , sending an extra
* ACK when there is nothing else to do in DELACK is not a big
* deal after all .
2005-08-10 07:14:34 +04:00
*/
/* Stop the PARTOPEN timer */
if ( sk - > sk_state = = DCCP_PARTOPEN )
inet_csk_clear_xmit_timer ( sk , ICSK_TIME_DACK ) ;
2010-06-22 05:14:35 +04:00
/* Obtain usec RTT sample from SYN exchange (used by TFRC). */
if ( likely ( sample ) ) {
long delta = dccp_timestamp ( ) - sample ;
dp - > dccps_syn_rtt = dccp_sample_rtt ( sk , 10 * delta ) ;
}
dp - > dccps_osr = DCCP_SKB_CB ( skb ) - > dccpd_seq ;
2005-08-10 07:14:34 +04:00
dccp_set_state ( sk , DCCP_OPEN ) ;
2005-10-11 08:25:00 +04:00
if ( dh - > dccph_type = = DCCP_PKT_DATAACK | |
dh - > dccph_type = = DCCP_PKT_DATA ) {
2006-01-04 01:25:17 +03:00
__dccp_rcv_established ( sk , skb , dh , len ) ;
2005-08-14 03:34:54 +04:00
queued = 1 ; /* packet was queued
2006-01-04 01:25:17 +03:00
( by __dccp_rcv_established ) */
2005-08-10 07:14:34 +04:00
}
break ;
}
return queued ;
}
int dccp_rcv_state_process ( struct sock * sk , struct sk_buff * skb ,
2012-04-15 09:58:06 +04:00
struct dccp_hdr * dh , unsigned int len )
2005-08-10 07:14:34 +04:00
{
struct dccp_sock * dp = dccp_sk ( sk ) ;
2005-09-17 03:58:33 +04:00
struct dccp_skb_cb * dcb = DCCP_SKB_CB ( skb ) ;
2005-08-10 07:14:34 +04:00
const int old_state = sk - > sk_state ;
2017-03-01 19:39:49 +03:00
bool acceptable ;
2005-08-10 07:14:34 +04:00
int queued = 0 ;
2005-08-14 03:36:01 +04:00
/*
* Step 3 : Process LISTEN state
*
* If S . state = = LISTEN ,
2006-11-10 21:29:14 +03:00
* If P . type = = Request or P contains a valid Init Cookie option ,
* ( * Must scan the packet ' s options to check for Init
* Cookies . Only Init Cookies are processed here ,
* however ; other options are processed in Step 8. This
* scan need only be performed if the endpoint uses Init
* Cookies * )
* ( * Generate a new socket and switch to that socket * )
* Set S : = new socket for this port pair
* S . state = RESPOND
* Choose S . ISS ( initial seqno ) or set from Init Cookies
* Initialize S . GAR : = S . ISS
* Set S . ISR , S . GSR , S . SWL , S . SWH from packet or Init
* Cookies Continue with S . state = = RESPOND
* ( * A Response packet will be generated in Step 11 * )
* Otherwise ,
* Generate Reset ( No Connection ) unless P . type = = Reset
* Drop packet and return
2005-08-14 03:36:01 +04:00
*/
if ( sk - > sk_state = = DCCP_LISTEN ) {
if ( dh - > dccph_type = = DCCP_PKT_REQUEST ) {
2017-03-01 19:39:49 +03:00
/* It is possible that we process SYN packets from backlog,
2018-10-02 01:02:26 +03:00
* so we need to make sure to disable BH and RCU right there .
2017-03-01 19:39:49 +03:00
*/
2018-10-02 01:02:26 +03:00
rcu_read_lock ( ) ;
2017-03-01 19:39:49 +03:00
local_bh_disable ( ) ;
acceptable = inet_csk ( sk ) - > icsk_af_ops - > conn_request ( sk , skb ) > = 0 ;
local_bh_enable ( ) ;
2018-10-02 01:02:26 +03:00
rcu_read_unlock ( ) ;
2017-03-01 19:39:49 +03:00
if ( ! acceptable )
2005-08-14 03:36:01 +04:00
return 1 ;
2017-02-16 19:22:46 +03:00
consume_skb ( skb ) ;
return 0 ;
2005-08-14 03:36:01 +04:00
}
if ( dh - > dccph_type = = DCCP_PKT_RESET )
goto discard ;
2005-09-17 03:58:33 +04:00
/* Caller (dccp_v4_do_rcv) will send Reset */
dcb - > dccpd_reset_code = DCCP_RESET_CODE_NO_CONNECTION ;
2005-08-14 03:36:01 +04:00
return 1 ;
2011-03-02 10:02:07 +03:00
} else if ( sk - > sk_state = = DCCP_CLOSED ) {
dcb - > dccpd_reset_code = DCCP_RESET_CODE_NO_CONNECTION ;
return 1 ;
2005-08-14 03:36:01 +04:00
}
dccp: Clean up slow-path input processing
This patch rearranges the order of statements of the slow-path input processing
(i.e. any other state than OPEN), to resolve the following issues.
1. Dependencies: the order of statements now better matches RFC 4340, 8.5, i.e.
step 7 is before step 9 (previously 9 was before 7), and parsing options in
step 8 (which may consume resources) now comes after step 7.
2. Sequence number checks are omitted if in state LISTEN/REQUEST, due to the
note underneath the table in RFC 4340, 7.5.3.
As a result, CCID processing is now indeed confined to OPEN/PARTOPEN states,
i.e. congestion control is performed only on the flow of data packets. This
avoids pathological cases of doing congestion control on those messages
which set up and terminate the connection.
3. Packets are now passed on to Ack Vector / CCID processing only after
- step 7 (receive unexpected packets),
- step 9 (receive Reset),
- step 13 (receive CloseReq),
- step 14 (receive Close)
and only if the state is PARTOPEN. This simplifies CCID processing:
- in LISTEN/CLOSED the CCIDs are non-existent;
- in RESPOND/REQUEST the CCIDs have not yet been negotiated;
- in CLOSEREQ and active-CLOSING the node has already closed this socket;
- in passive-CLOSING the client is waiting for its Reset.
In the last case, RFC 4340, 8.3 leaves it open to ignore further incoming
data, which is the approach taken here.
Signed-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>
2011-07-03 19:49:16 +04:00
/* Step 6: Check sequence numbers (omitted in LISTEN/REQUEST state) */
if ( sk - > sk_state ! = DCCP_REQUESTING & & dccp_check_seqno ( sk , skb ) )
goto discard ;
2005-08-10 07:14:34 +04:00
dccp: Clean up slow-path input processing
This patch rearranges the order of statements of the slow-path input processing
(i.e. any other state than OPEN), to resolve the following issues.
1. Dependencies: the order of statements now better matches RFC 4340, 8.5, i.e.
step 7 is before step 9 (previously 9 was before 7), and parsing options in
step 8 (which may consume resources) now comes after step 7.
2. Sequence number checks are omitted if in state LISTEN/REQUEST, due to the
note underneath the table in RFC 4340, 7.5.3.
As a result, CCID processing is now indeed confined to OPEN/PARTOPEN states,
i.e. congestion control is performed only on the flow of data packets. This
avoids pathological cases of doing congestion control on those messages
which set up and terminate the connection.
3. Packets are now passed on to Ack Vector / CCID processing only after
- step 7 (receive unexpected packets),
- step 9 (receive Reset),
- step 13 (receive CloseReq),
- step 14 (receive Close)
and only if the state is PARTOPEN. This simplifies CCID processing:
- in LISTEN/CLOSED the CCIDs are non-existent;
- in RESPOND/REQUEST the CCIDs have not yet been negotiated;
- in CLOSEREQ and active-CLOSING the node has already closed this socket;
- in passive-CLOSING the client is waiting for its Reset.
In the last case, RFC 4340, 8.3 leaves it open to ignore further incoming
data, which is the approach taken here.
Signed-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>
2011-07-03 19:49:16 +04:00
/*
* Step 7 : Check for unexpected packet types
* If ( S . is_server and P . type = = Response )
* or ( S . is_client and P . type = = Request )
* or ( S . state = = RESPOND and P . type = = Data ) ,
* Send Sync packet acknowledging P . seqno
* Drop packet and return
*/
if ( ( dp - > dccps_role ! = DCCP_ROLE_CLIENT & &
dh - > dccph_type = = DCCP_PKT_RESPONSE ) | |
( dp - > dccps_role = = DCCP_ROLE_CLIENT & &
dh - > dccph_type = = DCCP_PKT_REQUEST ) | |
( sk - > sk_state = = DCCP_RESPOND & & dh - > dccph_type = = DCCP_PKT_DATA ) ) {
dccp_send_sync ( sk , dcb - > dccpd_seq , DCCP_PKT_SYNC ) ;
goto discard ;
2008-09-09 15:27:22 +04:00
}
dccp: Clean up slow-path input processing
This patch rearranges the order of statements of the slow-path input processing
(i.e. any other state than OPEN), to resolve the following issues.
1. Dependencies: the order of statements now better matches RFC 4340, 8.5, i.e.
step 7 is before step 9 (previously 9 was before 7), and parsing options in
step 8 (which can consume resources) now comes after step 7.
2. Bug-fix: in state CLOSED, there should not be any sequence number checking
or option processing. This is why the test for CLOSED has been moved after
the test for LISTEN.
3. As before sequence number checks are omitted if in state LISTEN/REQUEST, due
to the note underneath the table in RFC 4340, 7.5.3.
4. Packets are now passed on to Ack Vector / CCID processing only after
- step 7 (receive unexpected packets),
- step 9 (receive Reset),
- step 13 (receive CloseReq),
- step 14 (receive Close)
and only if the state is PARTOPEN. This simplifies CCID processing:
- in LISTEN/CLOSED the CCIDs are non-existent;
- in RESPOND/REQUEST the CCIDs have not yet been negotiated;
- in CLOSEREQ and active-CLOSING the node has already closed this socket;
- in passive-CLOSING the client is waiting for its Reset.
In the last case, RFC 4340, 8.3 leaves it open to ignore further incoming
data, which is the approach taken here.
As a result of (3), CCID processing is now indeed confined to OPEN/PARTOPEN
states, i.e. congestion control is performed only on the flow of data packets.
This avoids pathological cases of doing congestion control on those messages
which set up and terminate the connection.
I have done a few checks to see if this creates a problem in other parts of
the code. This seems not to be the case; even if there were one, it would be
better to fix it than to perform congestion control on Close/Request/Response
messages. Similarly for Ack Vectors (as they depend on the negotiated CCID).
Signed-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>
2008-09-04 09:30:19 +04:00
dccp: Clean up slow-path input processing
This patch rearranges the order of statements of the slow-path input processing
(i.e. any other state than OPEN), to resolve the following issues.
1. Dependencies: the order of statements now better matches RFC 4340, 8.5, i.e.
step 7 is before step 9 (previously 9 was before 7), and parsing options in
step 8 (which may consume resources) now comes after step 7.
2. Sequence number checks are omitted if in state LISTEN/REQUEST, due to the
note underneath the table in RFC 4340, 7.5.3.
As a result, CCID processing is now indeed confined to OPEN/PARTOPEN states,
i.e. congestion control is performed only on the flow of data packets. This
avoids pathological cases of doing congestion control on those messages
which set up and terminate the connection.
3. Packets are now passed on to Ack Vector / CCID processing only after
- step 7 (receive unexpected packets),
- step 9 (receive Reset),
- step 13 (receive CloseReq),
- step 14 (receive Close)
and only if the state is PARTOPEN. This simplifies CCID processing:
- in LISTEN/CLOSED the CCIDs are non-existent;
- in RESPOND/REQUEST the CCIDs have not yet been negotiated;
- in CLOSEREQ and active-CLOSING the node has already closed this socket;
- in passive-CLOSING the client is waiting for its Reset.
In the last case, RFC 4340, 8.3 leaves it open to ignore further incoming
data, which is the approach taken here.
Signed-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>
2011-07-03 19:49:16 +04:00
/* Step 8: Process options */
if ( dccp_parse_options ( sk , NULL , skb ) )
return 1 ;
2005-08-10 07:14:34 +04:00
/*
* Step 9 : Process Reset
* If P . type = = Reset ,
* Tear down connection
* S . state : = TIMEWAIT
* Set TIMEWAIT timer
* Drop packet and return
dccp: Clean up slow-path input processing
This patch rearranges the order of statements of the slow-path input processing
(i.e. any other state than OPEN), to resolve the following issues.
1. Dependencies: the order of statements now better matches RFC 4340, 8.5, i.e.
step 7 is before step 9 (previously 9 was before 7), and parsing options in
step 8 (which may consume resources) now comes after step 7.
2. Sequence number checks are omitted if in state LISTEN/REQUEST, due to the
note underneath the table in RFC 4340, 7.5.3.
As a result, CCID processing is now indeed confined to OPEN/PARTOPEN states,
i.e. congestion control is performed only on the flow of data packets. This
avoids pathological cases of doing congestion control on those messages
which set up and terminate the connection.
3. Packets are now passed on to Ack Vector / CCID processing only after
- step 7 (receive unexpected packets),
- step 9 (receive Reset),
- step 13 (receive CloseReq),
- step 14 (receive Close)
and only if the state is PARTOPEN. This simplifies CCID processing:
- in LISTEN/CLOSED the CCIDs are non-existent;
- in RESPOND/REQUEST the CCIDs have not yet been negotiated;
- in CLOSEREQ and active-CLOSING the node has already closed this socket;
- in passive-CLOSING the client is waiting for its Reset.
In the last case, RFC 4340, 8.3 leaves it open to ignore further incoming
data, which is the approach taken here.
Signed-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>
2011-07-03 19:49:16 +04:00
*/
2005-08-10 07:14:34 +04:00
if ( dh - > dccph_type = = DCCP_PKT_RESET ) {
[DCCP]: Convert Reset code into socket error number
This adds support for converting the 11 currently defined Reset codes into system
error numbers, which are stored in sk_err for further interpretation.
This makes the externally visible API behaviour similar to TCP, since a client
connecting to a non-existing port will experience ECONNREFUSED.
* Code 0, Unspecified, is interpreted as non-error (0);
* Code 1, Closed (normal termination), also maps into 0;
* Code 2, Aborted, maps into "Connection reset by peer" (ECONNRESET);
* Code 3, No Connection and
Code 7, Connection Refused, map into "Connection refused" (ECONNREFUSED);
* Code 4, Packet Error, maps into "No message of desired type" (ENOMSG);
* Code 5, Option Error, maps into "Illegal byte sequence" (EILSEQ);
* Code 6, Mandatory Error, maps into "Operation not supported on transport endpoint" (EOPNOTSUPP);
* Code 8, Bad Service Code, maps into "Invalid request code" (EBADRQC);
* Code 9, Too Busy, maps into "Too many users" (EUSERS);
* Code 10, Bad Init Cookie, maps into "Invalid request descriptor" (EBADR);
* Code 11, Aggression Penalty, maps into "Quota exceeded" (EDQUOT)
which makes sense in terms of using more than the `fair share' of bandwidth.
Signed-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>
Acked-by: Ian McDonald <ian.mcdonald@jandi.co.nz>
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2007-10-24 16:27:48 +04:00
dccp_rcv_reset ( sk , skb ) ;
2005-08-10 07:14:34 +04:00
return 0 ;
dccp: Clean up slow-path input processing
This patch rearranges the order of statements of the slow-path input processing
(i.e. any other state than OPEN), to resolve the following issues.
1. Dependencies: the order of statements now better matches RFC 4340, 8.5, i.e.
step 7 is before step 9 (previously 9 was before 7), and parsing options in
step 8 (which may consume resources) now comes after step 7.
2. Sequence number checks are omitted if in state LISTEN/REQUEST, due to the
note underneath the table in RFC 4340, 7.5.3.
As a result, CCID processing is now indeed confined to OPEN/PARTOPEN states,
i.e. congestion control is performed only on the flow of data packets. This
avoids pathological cases of doing congestion control on those messages
which set up and terminate the connection.
3. Packets are now passed on to Ack Vector / CCID processing only after
- step 7 (receive unexpected packets),
- step 9 (receive Reset),
- step 13 (receive CloseReq),
- step 14 (receive Close)
and only if the state is PARTOPEN. This simplifies CCID processing:
- in LISTEN/CLOSED the CCIDs are non-existent;
- in RESPOND/REQUEST the CCIDs have not yet been negotiated;
- in CLOSEREQ and active-CLOSING the node has already closed this socket;
- in passive-CLOSING the client is waiting for its Reset.
In the last case, RFC 4340, 8.3 leaves it open to ignore further incoming
data, which is the approach taken here.
Signed-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>
2011-07-03 19:49:16 +04:00
} else if ( dh - > dccph_type = = DCCP_PKT_CLOSEREQ ) { /* Step 13 */
[DCCP]: Integrate state transitions for passive-close
This adds the necessary state transitions for the two forms of passive-close
* PASSIVE_CLOSE - which is entered when a host receives a Close;
* PASSIVE_CLOSEREQ - which is entered when a client receives a CloseReq.
Here is a detailed account of what the patch does in each state.
1) Receiving CloseReq
The pseudo-code in 8.5 says:
Step 13: Process CloseReq
If P.type == CloseReq and S.state < CLOSEREQ,
Generate Close
S.state := CLOSING
Set CLOSING timer.
This means we need to address what to do in CLOSED, LISTEN, REQUEST, RESPOND, PARTOPEN, and OPEN.
* CLOSED: silently ignore - it may be a late or duplicate CloseReq;
* LISTEN/RESPOND: will not appear, since Step 7 is performed first (we know we are the client);
* REQUEST: perform Step 13 directly (no need to enqueue packet);
* OPEN/PARTOPEN: enter PASSIVE_CLOSEREQ so that the application has a chance to process unread data.
When already in PASSIVE_CLOSEREQ, no second CloseReq is enqueued. In any other state, the CloseReq is ignored.
I think that this offers some robustness against rare and pathological cases: e.g. a simultaneous close where
the client sends a Close and the server a CloseReq. The client will then be retransmitting its Close until it
gets the Reset, so ignoring the CloseReq while in state CLOSING is sane.
2) Receiving Close
The code below from 8.5 is unconditional.
Step 14: Process Close
If P.type == Close,
Generate Reset(Closed)
Tear down connection
Drop packet and return
Thus we need to consider all states:
* CLOSED: silently ignore, since this can happen when a retransmitted or late Close arrives;
* LISTEN: dccp_rcv_state_process() will generate a Reset ("No Connection");
* REQUEST: perform Step 14 directly (no need to enqueue packet);
* RESPOND: dccp_check_req() will generate a Reset ("Packet Error") -- left it at that;
* OPEN/PARTOPEN: enter PASSIVE_CLOSE so that application has a chance to process unread data;
* CLOSEREQ: server performed active-close -- perform Step 14;
* CLOSING: simultaneous-close: use a tie-breaker to avoid message ping-pong (see comment);
* PASSIVE_CLOSEREQ: ignore - the peer has a bug (sending first a CloseReq and now a Close);
* TIMEWAIT: packet is ignored.
Note that the condition of receiving a packet in state CLOSED here is different from the condition "there
is no socket for such a connection": the socket still exists, but its state indicates it is unusable.
Last, dccp_finish_passive_close sets either DCCP_CLOSED or DCCP_CLOSING = TCP_CLOSING, so that
sk_stream_wait_close() will wait for the final Reset (which will trigger CLOSING => CLOSED).
Signed-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2007-11-28 16:59:48 +03:00
if ( dccp_rcv_closereq ( sk , skb ) )
return 0 ;
2005-08-24 08:50:06 +04:00
goto discard ;
dccp: Clean up slow-path input processing
This patch rearranges the order of statements of the slow-path input processing
(i.e. any other state than OPEN), to resolve the following issues.
1. Dependencies: the order of statements now better matches RFC 4340, 8.5, i.e.
step 7 is before step 9 (previously 9 was before 7), and parsing options in
step 8 (which may consume resources) now comes after step 7.
2. Sequence number checks are omitted if in state LISTEN/REQUEST, due to the
note underneath the table in RFC 4340, 7.5.3.
As a result, CCID processing is now indeed confined to OPEN/PARTOPEN states,
i.e. congestion control is performed only on the flow of data packets. This
avoids pathological cases of doing congestion control on those messages
which set up and terminate the connection.
3. Packets are now passed on to Ack Vector / CCID processing only after
- step 7 (receive unexpected packets),
- step 9 (receive Reset),
- step 13 (receive CloseReq),
- step 14 (receive Close)
and only if the state is PARTOPEN. This simplifies CCID processing:
- in LISTEN/CLOSED the CCIDs are non-existent;
- in RESPOND/REQUEST the CCIDs have not yet been negotiated;
- in CLOSEREQ and active-CLOSING the node has already closed this socket;
- in passive-CLOSING the client is waiting for its Reset.
In the last case, RFC 4340, 8.3 leaves it open to ignore further incoming
data, which is the approach taken here.
Signed-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>
2011-07-03 19:49:16 +04:00
} else if ( dh - > dccph_type = = DCCP_PKT_CLOSE ) { /* Step 14 */
[DCCP]: Integrate state transitions for passive-close
This adds the necessary state transitions for the two forms of passive-close
* PASSIVE_CLOSE - which is entered when a host receives a Close;
* PASSIVE_CLOSEREQ - which is entered when a client receives a CloseReq.
Here is a detailed account of what the patch does in each state.
1) Receiving CloseReq
The pseudo-code in 8.5 says:
Step 13: Process CloseReq
If P.type == CloseReq and S.state < CLOSEREQ,
Generate Close
S.state := CLOSING
Set CLOSING timer.
This means we need to address what to do in CLOSED, LISTEN, REQUEST, RESPOND, PARTOPEN, and OPEN.
* CLOSED: silently ignore - it may be a late or duplicate CloseReq;
* LISTEN/RESPOND: will not appear, since Step 7 is performed first (we know we are the client);
* REQUEST: perform Step 13 directly (no need to enqueue packet);
* OPEN/PARTOPEN: enter PASSIVE_CLOSEREQ so that the application has a chance to process unread data.
When already in PASSIVE_CLOSEREQ, no second CloseReq is enqueued. In any other state, the CloseReq is ignored.
I think that this offers some robustness against rare and pathological cases: e.g. a simultaneous close where
the client sends a Close and the server a CloseReq. The client will then be retransmitting its Close until it
gets the Reset, so ignoring the CloseReq while in state CLOSING is sane.
2) Receiving Close
The code below from 8.5 is unconditional.
Step 14: Process Close
If P.type == Close,
Generate Reset(Closed)
Tear down connection
Drop packet and return
Thus we need to consider all states:
* CLOSED: silently ignore, since this can happen when a retransmitted or late Close arrives;
* LISTEN: dccp_rcv_state_process() will generate a Reset ("No Connection");
* REQUEST: perform Step 14 directly (no need to enqueue packet);
* RESPOND: dccp_check_req() will generate a Reset ("Packet Error") -- left it at that;
* OPEN/PARTOPEN: enter PASSIVE_CLOSE so that application has a chance to process unread data;
* CLOSEREQ: server performed active-close -- perform Step 14;
* CLOSING: simultaneous-close: use a tie-breaker to avoid message ping-pong (see comment);
* PASSIVE_CLOSEREQ: ignore - the peer has a bug (sending first a CloseReq and now a Close);
* TIMEWAIT: packet is ignored.
Note that the condition of receiving a packet in state CLOSED here is different from the condition "there
is no socket for such a connection": the socket still exists, but its state indicates it is unusable.
Last, dccp_finish_passive_close sets either DCCP_CLOSED or DCCP_CLOSING = TCP_CLOSING, so that
sk_stream_wait_close() will wait for the final Reset (which will trigger CLOSING => CLOSED).
Signed-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2007-11-28 16:59:48 +03:00
if ( dccp_rcv_close ( sk , skb ) )
return 0 ;
goto discard ;
2005-08-10 07:14:34 +04:00
}
switch ( sk - > sk_state ) {
case DCCP_REQUESTING :
queued = dccp_rcv_request_sent_state_process ( sk , skb , dh , len ) ;
if ( queued > = 0 )
return queued ;
__kfree_skb ( skb ) ;
return 0 ;
2008-09-09 15:27:22 +04:00
case DCCP_PARTOPEN :
dccp: Clean up slow-path input processing
This patch rearranges the order of statements of the slow-path input processing
(i.e. any other state than OPEN), to resolve the following issues.
1. Dependencies: the order of statements now better matches RFC 4340, 8.5, i.e.
step 7 is before step 9 (previously 9 was before 7), and parsing options in
step 8 (which may consume resources) now comes after step 7.
2. Sequence number checks are omitted if in state LISTEN/REQUEST, due to the
note underneath the table in RFC 4340, 7.5.3.
As a result, CCID processing is now indeed confined to OPEN/PARTOPEN states,
i.e. congestion control is performed only on the flow of data packets. This
avoids pathological cases of doing congestion control on those messages
which set up and terminate the connection.
3. Packets are now passed on to Ack Vector / CCID processing only after
- step 7 (receive unexpected packets),
- step 9 (receive Reset),
- step 13 (receive CloseReq),
- step 14 (receive Close)
and only if the state is PARTOPEN. This simplifies CCID processing:
- in LISTEN/CLOSED the CCIDs are non-existent;
- in RESPOND/REQUEST the CCIDs have not yet been negotiated;
- in CLOSEREQ and active-CLOSING the node has already closed this socket;
- in passive-CLOSING the client is waiting for its Reset.
In the last case, RFC 4340, 8.3 leaves it open to ignore further incoming
data, which is the approach taken here.
Signed-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>
2011-07-03 19:49:16 +04:00
/* Step 8: if using Ack Vectors, mark packet acknowledgeable */
dccp_handle_ackvec_processing ( sk , skb ) ;
dccp_deliver_input_to_ccids ( sk , skb ) ;
2020-08-24 01:36:59 +03:00
fallthrough ;
dccp: Clean up slow-path input processing
This patch rearranges the order of statements of the slow-path input processing
(i.e. any other state than OPEN), to resolve the following issues.
1. Dependencies: the order of statements now better matches RFC 4340, 8.5, i.e.
step 7 is before step 9 (previously 9 was before 7), and parsing options in
step 8 (which may consume resources) now comes after step 7.
2. Sequence number checks are omitted if in state LISTEN/REQUEST, due to the
note underneath the table in RFC 4340, 7.5.3.
As a result, CCID processing is now indeed confined to OPEN/PARTOPEN states,
i.e. congestion control is performed only on the flow of data packets. This
avoids pathological cases of doing congestion control on those messages
which set up and terminate the connection.
3. Packets are now passed on to Ack Vector / CCID processing only after
- step 7 (receive unexpected packets),
- step 9 (receive Reset),
- step 13 (receive CloseReq),
- step 14 (receive Close)
and only if the state is PARTOPEN. This simplifies CCID processing:
- in LISTEN/CLOSED the CCIDs are non-existent;
- in RESPOND/REQUEST the CCIDs have not yet been negotiated;
- in CLOSEREQ and active-CLOSING the node has already closed this socket;
- in passive-CLOSING the client is waiting for its Reset.
In the last case, RFC 4340, 8.3 leaves it open to ignore further incoming
data, which is the approach taken here.
Signed-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>
2011-07-03 19:49:16 +04:00
case DCCP_RESPOND :
2005-08-14 03:34:54 +04:00
queued = dccp_rcv_respond_partopen_state_process ( sk , skb ,
dh , len ) ;
2005-08-10 07:14:34 +04:00
break ;
}
2005-08-14 03:34:54 +04:00
if ( dh - > dccph_type = = DCCP_PKT_ACK | |
dh - > dccph_type = = DCCP_PKT_DATAACK ) {
2005-08-10 07:14:34 +04:00
switch ( old_state ) {
case DCCP_PARTOPEN :
sk - > sk_state_change ( sk ) ;
2007-11-26 15:10:50 +03:00
sk_wake_async ( sk , SOCK_WAKE_IO , POLL_OUT ) ;
2005-08-10 07:14:34 +04:00
break ;
}
2007-09-26 17:30:05 +04:00
} else if ( unlikely ( dh - > dccph_type = = DCCP_PKT_SYNC ) ) {
dccp_send_sync ( sk , dcb - > dccpd_seq , DCCP_PKT_SYNCACK ) ;
goto discard ;
2005-08-10 07:14:34 +04:00
}
2006-12-10 21:01:18 +03:00
if ( ! queued ) {
2005-08-10 07:14:34 +04:00
discard :
__kfree_skb ( skb ) ;
}
return 0 ;
}
2005-12-14 10:24:16 +03:00
EXPORT_SYMBOL_GPL ( dccp_rcv_state_process ) ;
2007-03-20 21:23:18 +03:00
/**
2007-09-26 09:40:44 +04:00
* dccp_sample_rtt - Validate and finalise computation of RTT sample
2020-07-13 02:15:00 +03:00
* @ sk : socket structure
2007-09-26 09:40:44 +04:00
* @ delta : number of microseconds between packet and acknowledgment
2012-07-10 14:55:09 +04:00
*
2007-09-26 09:40:44 +04:00
* The routine is kept generic to work in different contexts . It should be
* called immediately when the ACK used for the RTT sample arrives .
2007-03-20 21:23:18 +03:00
*/
2007-09-26 09:40:44 +04:00
u32 dccp_sample_rtt ( struct sock * sk , long delta )
2007-03-20 21:23:18 +03:00
{
2007-09-26 09:40:44 +04:00
/* dccpor_elapsed_time is either zeroed out or set and > 0 */
delta - = dccp_sk ( sk ) - > dccps_options_received . dccpor_elapsed_time * 10 ;
2007-03-20 21:23:18 +03:00
2008-09-09 15:27:22 +04:00
if ( unlikely ( delta < = 0 ) ) {
DCCP_WARN ( " unusable RTT sample %ld, using min \n " , delta ) ;
return DCCP_SANE_RTT_MIN ;
}
if ( unlikely ( delta > DCCP_SANE_RTT_MAX ) ) {
DCCP_WARN ( " RTT sample %ld too large, using max \n " , delta ) ;
return DCCP_SANE_RTT_MAX ;
}
return delta ;
2007-03-20 21:23:18 +03:00
}
