2005-08-10 03:14:34 +00:00
|
|
|
/*
|
|
|
|
|
* net/dccp/input.c
|
2006-12-10 18:01:18 +00:00
|
|
|
*
|
2005-08-10 03:14:34 +00:00
|
|
|
* An implementation of the DCCP protocol
|
|
|
|
|
* Arnaldo Carvalho de Melo <acme@conectiva.com.br>
|
|
|
|
|
*
|
|
|
|
|
* This program is free software; you can redistribute it and/or
|
|
|
|
|
* modify it under the terms of the GNU General Public License
|
|
|
|
|
* as published by the Free Software Foundation; either version
|
|
|
|
|
* 2 of the License, or (at your option) any later version.
|
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
#include <linux/dccp.h>
|
|
|
|
|
#include <linux/skbuff.h>
|
|
|
|
|
|
|
|
|
|
#include <net/sock.h>
|
|
|
|
|
|
2005-09-18 07:17:51 +00:00
|
|
|
#include "ackvec.h"
|
2005-08-10 03:14:34 +00:00
|
|
|
#include "ccid.h"
|
|
|
|
|
#include "dccp.h"
|
|
|
|
|
|
2007-10-18 02:33:06 +00: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 13:28:43 +00:00
|
|
|
static void dccp_enqueue_skb(struct sock *sk, struct sk_buff *skb)
|
2005-08-10 03:14:34 +00:00
|
|
|
{
|
|
|
|
|
__skb_pull(skb, dccp_hdr(skb)->dccph_doff * 4);
|
|
|
|
|
__skb_queue_tail(&sk->sk_receive_queue, skb);
|
|
|
|
|
skb_set_owner_r(skb, sk);
|
|
|
|
|
sk->sk_data_ready(sk, 0);
|
|
|
|
|
}
|
|
|
|
|
|
2007-12-13 13:28:43 +00: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 13:59:48 +00:00
|
|
|
static int dccp_rcv_close(struct sock *sk, struct sk_buff *skb)
|
2005-08-10 03:14:34 +00: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 13:59:48 +00: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;
|
|
|
|
|
/* fall through */
|
|
|
|
|
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);
|
|
|
|
|
/* fall through */
|
|
|
|
|
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 03:14:34 +00: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 13:59:48 +00:00
|
|
|
static int dccp_rcv_closereq(struct sock *sk, struct sk_buff *skb)
|
2005-08-10 03:14:34 +00: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 13:59:48 +00:00
|
|
|
int queued = 0;
|
|
|
|
|
|
2005-08-10 03:14:34 +00: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 06:10:59 +00: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 13:59:48 +00:00
|
|
|
return queued;
|
2005-08-10 03:14:34 +00: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 13:59:48 +00:00
|
|
|
/* Step 13: process relevant Client states < CLOSEREQ */
|
|
|
|
|
switch (sk->sk_state) {
|
|
|
|
|
case DCCP_REQUESTING:
|
|
|
|
|
dccp_send_close(sk, 0);
|
2005-09-13 22:03:15 +00: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 13:59:48 +00: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);
|
|
|
|
|
/* fall through */
|
|
|
|
|
case DCCP_PASSIVE_CLOSEREQ:
|
|
|
|
|
sk_wake_async(sk, SOCK_WAKE_WAITD, POLL_HUP);
|
|
|
|
|
}
|
|
|
|
|
return queued;
|
2005-08-10 03:14:34 +00:00
|
|
|
}
|
|
|
|
|
|
[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 12:27:48 +00:00
|
|
|
static u8 dccp_reset_code_convert(const u8 code)
|
|
|
|
|
{
|
|
|
|
|
const u8 error_code[] = {
|
|
|
|
|
[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)
|
|
|
|
|
{
|
|
|
|
|
u8 err = dccp_reset_code_convert(dccp_hdr_reset(skb)->dccph_reset_code);
|
|
|
|
|
|
|
|
|
|
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 12:10:50 +00: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 12:27:48 +00:00
|
|
|
dccp_time_wait(sk, DCCP_TIME_WAIT, 0);
|
|
|
|
|
}
|
|
|
|
|
|
2006-03-21 05:58:56 +00:00
|
|
|
static void dccp_event_ack_recv(struct sock *sk, struct sk_buff *skb)
|
2005-08-10 03:14:34 +00:00
|
|
|
{
|
|
|
|
|
struct dccp_sock *dp = dccp_sk(sk);
|
|
|
|
|
|
dccp ccid-2: Phase out the use of boolean Ack Vector sysctl
This removes the use of the sysctl and the minisock variable for the Send Ack
Vector feature, which is now handled fully dynamically via feature negotiation;
i.e. when CCID2 is enabled, Ack Vectors are automatically enabled (as per
RFC 4341, 4.).
Using a sysctl in parallel to this implementation would open the door to
crashes, since much of the code relies on tests of the boolean minisock /
sysctl variable. Thus, this patch replaces all tests of type
if (dccp_msk(sk)->dccpms_send_ack_vector)
/* ... */
with
if (dp->dccps_hc_rx_ackvec != NULL)
/* ... */
The dccps_hc_rx_ackvec is allocated by the dccp_hdlr_ackvec() when feature
negotiation concluded that Ack Vectors are to be used on the half-connection.
Otherwise, it is NULL (due to dccp_init_sock/dccp_create_openreq_child),
so that the test is a valid one.
The activation handler for Ack Vectors is called as soon as the feature
negotiation has concluded at the
* server when the Ack marking the transition RESPOND => OPEN arrives;
* client after it has sent its ACK, marking the transition REQUEST => PARTOPEN.
Adding the sequence number of the Response packet to the Ack Vector has been
removed, since
(a) connection establishment implies that the Response has been received;
(b) the CCIDs only look at packets received in the (PART)OPEN state, i.e.
this entry will always be ignored;
(c) it can not be used for anything useful - to detect loss for instance, only
packets received after the loss can serve as pseudo-dupacks.
Signed-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>
Acked-by: Ian McDonald <ian.mcdonald@jandi.co.nz>
2008-09-04 05:30:19 +00:00
|
|
|
if (dp->dccps_hc_rx_ackvec != NULL)
|
dccp ccid-2: Algorithm to update buffer state
This provides a routine to consistently update the buffer state when the
peer acknowledges receipt of Ack Vectors; updating state in the list of Ack
Vectors as well as in the circular buffer.
While based on RFC 4340, several additional (and necessary) precautions were
added to protect the consistency of the buffer state. These additions are
essential, since analysis and experience showed that the basic algorithm was
insufficient for this task (which lead to problems that were hard to debug).
The algorithm now
* deals with HC-sender acknowledging to HC-receiver and vice versa,
* keeps track of the last unacknowledged but received seqno in tail_ackno,
* has special cases to reset the overflow condition when appropriate,
* is protected against receiving older information (would mess up buffer state).
Note: The older code performed an unnecessary step, where the sender cleared
Ack Vector state by parsing the Ack Vector received by the HC-receiver. Doing
this was entirely redundant, since
* the receiver always puts the full acknowledgment window (groups 2,3 in 11.4.2)
into the Ack Vectors it sends; hence the HC-receiver is only interested in the
highest state that the HC-sender received;
* this means that the acknowledgment number on the (Data)Ack from the HC-sender
is sufficient; and work done in parsing earlier state is not necessary, since
the later state subsumes the earlier one (see also RFC 4340, A.4).
This older interface (dccp_ackvec_parse()) is therefore removed.
Signed-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>
2008-09-04 05:30:19 +00:00
|
|
|
dccp_ackvec_clear_state(dp->dccps_hc_rx_ackvec,
|
|
|
|
|
DCCP_SKB_CB(skb)->dccpd_ack_seq);
|
2005-08-10 03:14:34 +00: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 11:56:48 +00: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 03:14:34 +00: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 05:41:19 +00:00
|
|
|
u64 lswl, lawl, seqno = DCCP_SKB_CB(skb)->dccpd_seq,
|
|
|
|
|
ackno = DCCP_SKB_CB(skb)->dccpd_ack_seq;
|
2005-08-10 03:14:34 +00: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 18:01:18 +00:00
|
|
|
if (dh->dccph_type == DCCP_PKT_SYNC ||
|
2005-08-10 03:14:34 +00:00
|
|
|
dh->dccph_type == DCCP_PKT_SYNCACK) {
|
2007-09-26 05:41:19 +00: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 03:14:34 +00:00
|
|
|
else
|
|
|
|
|
return -1;
|
2005-08-17 06:10:59 +00:00
|
|
|
}
|
2007-02-09 14:24:38 +00:00
|
|
|
|
2005-08-10 03:14:34 +00: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 06:10:59 +00:00
|
|
|
lswl = dp->dccps_swl;
|
|
|
|
|
lawl = dp->dccps_awl;
|
|
|
|
|
|
|
|
|
|
if (dh->dccph_type == DCCP_PKT_CLOSEREQ ||
|
2005-08-19 00:12:02 +00:00
|
|
|
dh->dccph_type == DCCP_PKT_CLOSE ||
|
|
|
|
|
dh->dccph_type == DCCP_PKT_RESET) {
|
2007-09-26 05:41:19 +00:00
|
|
|
lswl = ADD48(dp->dccps_gsr, 1);
|
2005-08-10 03:14:34 +00:00
|
|
|
lawl = dp->dccps_gar;
|
|
|
|
|
}
|
|
|
|
|
|
2007-09-26 05:41:19 +00: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 03:14:34 +00:00
|
|
|
|
|
|
|
|
if (dh->dccph_type != DCCP_PKT_SYNC &&
|
2007-09-26 05:41:19 +00:00
|
|
|
(ackno != DCCP_PKT_WITHOUT_ACK_SEQ))
|
|
|
|
|
dp->dccps_gar = ackno;
|
2005-08-10 03:14:34 +00:00
|
|
|
} else {
|
2007-09-26 14:31:49 +00: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)))
|
|
|
|
|
return 0;
|
|
|
|
|
|
2006-11-20 20:39:23 +00:00
|
|
|
DCCP_WARN("DCCP: Step 6 failed for %s packet, "
|
|
|
|
|
"(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 05:41:19 +00:00
|
|
|
(unsigned long long) lswl, (unsigned long long) seqno,
|
2006-11-20 20:39:23 +00:00
|
|
|
(unsigned long long) dp->dccps_swh,
|
2007-09-26 05:41:19 +00:00
|
|
|
(ackno == DCCP_PKT_WITHOUT_ACK_SEQ) ? "doesn't exist"
|
|
|
|
|
: "exists",
|
|
|
|
|
(unsigned long long) lawl, (unsigned long long) ackno,
|
2006-11-20 20:39:23 +00:00
|
|
|
(unsigned long long) dp->dccps_awh);
|
2007-09-26 14:31:49 +00:00
|
|
|
|
|
|
|
|
dp->dccps_rate_last = now;
|
|
|
|
|
|
2007-09-26 05:41:56 +00:00
|
|
|
if (dh->dccph_type == DCCP_PKT_RESET)
|
|
|
|
|
seqno = dp->dccps_gsr;
|
2007-09-26 05:41:19 +00:00
|
|
|
dccp_send_sync(sk, seqno, DCCP_PKT_SYNC);
|
2005-08-10 03:14:34 +00:00
|
|
|
return -1;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
2006-03-21 05:58:56 +00:00
|
|
|
static int __dccp_rcv_established(struct sock *sk, struct sk_buff *skb,
|
|
|
|
|
const struct dccp_hdr *dh, const unsigned len)
|
2005-08-10 03:14:34 +00: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 11:56:48 +00: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 03:14:34 +00:00
|
|
|
*/
|
2007-12-13 13:28:43 +00:00
|
|
|
dccp_enqueue_skb(sk, skb);
|
2005-08-10 03:14:34 +00: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 12:27:48 +00:00
|
|
|
*/
|
|
|
|
|
dccp_rcv_reset(sk, skb);
|
2005-08-10 03:14:34 +00: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 13:59:48 +00:00
|
|
|
if (dccp_rcv_closereq(sk, skb))
|
|
|
|
|
return 0;
|
2005-08-10 03:14:34 +00: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 13:59:48 +00:00
|
|
|
if (dccp_rcv_close(sk, skb))
|
|
|
|
|
return 0;
|
|
|
|
|
goto discard;
|
2005-08-10 03:14:34 +00:00
|
|
|
case DCCP_PKT_REQUEST:
|
2006-12-10 18:01:18 +00:00
|
|
|
/* Step 7
|
|
|
|
|
* or (S.is_server and P.type == Response)
|
2005-08-10 03:14:34 +00: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 16:08:19 +00:00
|
|
|
if (dccp_delta_seqno(dp->dccps_osr,
|
|
|
|
|
DCCP_SKB_CB(skb)->dccpd_seq) >= 0) {
|
2005-08-10 03:14:34 +00:00
|
|
|
send_sync:
|
2005-08-17 06:10:59 +00:00
|
|
|
dccp_send_sync(sk, DCCP_SKB_CB(skb)->dccpd_seq,
|
|
|
|
|
DCCP_PKT_SYNC);
|
2005-08-10 03:14:34 +00:00
|
|
|
}
|
|
|
|
|
break;
|
2005-08-17 06:10:59 +00:00
|
|
|
case DCCP_PKT_SYNC:
|
|
|
|
|
dccp_send_sync(sk, DCCP_SKB_CB(skb)->dccpd_seq,
|
|
|
|
|
DCCP_PKT_SYNCACK);
|
|
|
|
|
/*
|
2006-10-24 23:17:51 +00:00
|
|
|
* From RFC 4340, sec. 5.7
|
2005-08-17 06:10:59 +00:00
|
|
|
*
|
|
|
|
|
* As with DCCP-Ack packets, DCCP-Sync and DCCP-SyncAck packets
|
|
|
|
|
* MAY have non-zero-length application data areas, whose
|
2006-10-24 23:17:51 +00:00
|
|
|
* contents receivers MUST ignore.
|
2005-08-17 06:10:59 +00:00
|
|
|
*/
|
|
|
|
|
goto discard;
|
2005-08-10 03:14:34 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
DCCP_INC_STATS_BH(DCCP_MIB_INERRS);
|
|
|
|
|
discard:
|
|
|
|
|
__kfree_skb(skb);
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
2006-01-03 22:25:17 +00:00
|
|
|
int dccp_rcv_established(struct sock *sk, struct sk_buff *skb,
|
|
|
|
|
const struct dccp_hdr *dh, const unsigned len)
|
|
|
|
|
{
|
|
|
|
|
struct dccp_sock *dp = dccp_sk(sk);
|
|
|
|
|
|
|
|
|
|
if (dccp_check_seqno(sk, skb))
|
|
|
|
|
goto discard;
|
|
|
|
|
|
2007-12-13 14:29:24 +00:00
|
|
|
if (dccp_parse_options(sk, NULL, skb))
|
2008-08-23 11:28:27 +00:00
|
|
|
return 1;
|
2006-01-03 22:25:17 +00:00
|
|
|
|
|
|
|
|
if (DCCP_SKB_CB(skb)->dccpd_ack_seq != DCCP_PKT_WITHOUT_ACK_SEQ)
|
|
|
|
|
dccp_event_ack_recv(sk, skb);
|
|
|
|
|
|
dccp ccid-2: Phase out the use of boolean Ack Vector sysctl
This removes the use of the sysctl and the minisock variable for the Send Ack
Vector feature, which is now handled fully dynamically via feature negotiation;
i.e. when CCID2 is enabled, Ack Vectors are automatically enabled (as per
RFC 4341, 4.).
Using a sysctl in parallel to this implementation would open the door to
crashes, since much of the code relies on tests of the boolean minisock /
sysctl variable. Thus, this patch replaces all tests of type
if (dccp_msk(sk)->dccpms_send_ack_vector)
/* ... */
with
if (dp->dccps_hc_rx_ackvec != NULL)
/* ... */
The dccps_hc_rx_ackvec is allocated by the dccp_hdlr_ackvec() when feature
negotiation concluded that Ack Vectors are to be used on the half-connection.
Otherwise, it is NULL (due to dccp_init_sock/dccp_create_openreq_child),
so that the test is a valid one.
The activation handler for Ack Vectors is called as soon as the feature
negotiation has concluded at the
* server when the Ack marking the transition RESPOND => OPEN arrives;
* client after it has sent its ACK, marking the transition REQUEST => PARTOPEN.
Adding the sequence number of the Response packet to the Ack Vector has been
removed, since
(a) connection establishment implies that the Response has been received;
(b) the CCIDs only look at packets received in the (PART)OPEN state, i.e.
this entry will always be ignored;
(c) it can not be used for anything useful - to detect loss for instance, only
packets received after the loss can serve as pseudo-dupacks.
Signed-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>
Acked-by: Ian McDonald <ian.mcdonald@jandi.co.nz>
2008-09-04 05:30:19 +00:00
|
|
|
if (dp->dccps_hc_rx_ackvec != NULL &&
|
2006-01-03 22:25:17 +00:00
|
|
|
dccp_ackvec_add(dp->dccps_hc_rx_ackvec, sk,
|
dccp ccid-2: Ack Vector interface clean-up
This patch brings the Ack Vector interface up to date. Its main purpose is
to lay the basis for the subsequent patches of this set, which will use the
new data structure fields and routines.
There are no real algorithmic changes, rather an adaptation:
(1) Replaced the static Ack Vector size (2) with a #define so that it can
be adapted (with low loss / Ack Ratio, a value of 1 works, so 2 seems
to be sufficient for the moment) and added a solution so that computing
the ECN nonce will continue to work - even with larger Ack Vectors.
(2) Replaced the #defines for Ack Vector states with a complete enum.
(3) Replaced #defines to compute Ack Vector length and state with general
purpose routines (inlines), and updated code to use these.
(4) Added a `tail' field (conversion to circular buffer in subsequent patch).
(5) Updated the (outdated) documentation for Ack Vector struct.
(6) All sequence number containers now trimmed to 48 bits.
(7) Removal of unused bits:
* removed dccpav_ack_nonce from struct dccp_ackvec, since this is already
redundantly stored in the `dccpavr_ack_nonce' (of Ack Vector record);
* removed Elapsed Time for Ack Vectors (it was nowhere used);
* replaced semantics of dccpavr_sent_len with dccpavr_ack_runlen, since
the code needs to be able to remember the old run length;
* reduced the de-/allocation routines (redundant / duplicate tests).
Justification for removing Elapsed Time information [can be removed]:
---------------------------------------------------------------------
1. The Elapsed Time information for Ack Vectors was nowhere used in the code.
2. DCCP does not implement rate-based pacing of acknowledgments. The only
recommendation for always including Elapsed Time is in section 11.3 of
RFC 4340: "Receivers that rate-pace acknowledgements SHOULD [...]
include Elapsed Time options". But such is not the case here.
3. It does not really improve estimation accuracy. The Elapsed Time field only
records the time between the arrival of the last acknowledgeable packet and
the time the Ack Vector is sent out. Since Linux does not (yet) implement
delayed Acks, the time difference will typically be small, since often the
arrival of a data packet triggers sending feedback at the HC-receiver.
Justification for changes in de-/allocation routines [can be removed]:
----------------------------------------------------------------------
* INIT_LIST_HEAD in dccp_ackvec_record_new was redundant, since the list
pointers were later overwritten when the node was added via list_add();
* dccp_ackvec_record_new() was called in a single place only;
* calls to list_del_init() before calling dccp_ackvec_record_delete() were
redundant, since subsequently the entire element was k-freed;
* since all calls to dccp_ackvec_record_delete() were preceded to a call to
list_del_init(), the WARN_ON test would never evaluate to true;
* since all calls to dccp_ackvec_record_delete() were made from within
list_for_each_entry_safe(), the test for avr == NULL was redundant;
* list_empty() in ackvec_free was redundant, since the same condition is
embedded in the loop condition of the subsequent list_for_each_entry_safe().
Signed-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>
2008-09-04 05:30:19 +00:00
|
|
|
DCCP_SKB_CB(skb)->dccpd_seq, DCCPAV_RECEIVED))
|
2006-01-03 22:25:17 +00:00
|
|
|
goto discard;
|
[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 11:56:48 +00:00
|
|
|
dccp_deliver_input_to_ccids(sk, skb);
|
2006-01-03 22:25:17 +00:00
|
|
|
|
|
|
|
|
return __dccp_rcv_established(sk, skb, dh, len);
|
|
|
|
|
discard:
|
|
|
|
|
__kfree_skb(skb);
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
2005-12-14 07:24:16 +00:00
|
|
|
EXPORT_SYMBOL_GPL(dccp_rcv_established);
|
|
|
|
|
|
2005-08-10 03:14:34 +00:00
|
|
|
static int dccp_rcv_request_sent_state_process(struct sock *sk,
|
|
|
|
|
struct sk_buff *skb,
|
|
|
|
|
const struct dccp_hdr *dh,
|
|
|
|
|
const unsigned len)
|
|
|
|
|
{
|
2006-12-10 18:01:18 +00:00
|
|
|
/*
|
2005-08-10 03:14:34 +00: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 05:40:44 +00:00
|
|
|
long tstamp = dccp_timestamp();
|
2005-08-10 03:14:34 +00:00
|
|
|
|
2005-08-13 23:34:54 +00:00
|
|
|
if (!between48(DCCP_SKB_CB(skb)->dccpd_ack_seq,
|
|
|
|
|
dp->dccps_awl, dp->dccps_awh)) {
|
|
|
|
|
dccp_pr_debug("invalid ackno: S.AWL=%llu, "
|
|
|
|
|
"P.ackno=%llu, S.AWH=%llu \n",
|
|
|
|
|
(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 03:14:34 +00:00
|
|
|
goto out_invalid_packet;
|
|
|
|
|
}
|
2006-01-03 22:25:49 +00:00
|
|
|
|
dccp: Integration of dynamic feature activation - part 3 (client side)
This integrates feature-activation in the client, with these details:
1. When dccp_parse_options() fails, the reset code is already set, request_sent
_state_process() currently overrides this with `Packet Error', which is not
intended - so changed to use the reset code set in dccp_parse_options();
2. There was a FIXME to change the error code when dccp_ackvec_add() fails.
I have looked this up and found that:
* the check whether ackno < ISN is already made earlier,
* this Response is likely the 1st packet with an Ackno that the client gets,
* so when dccp_ackvec_add() fails, the reason is likely not a packet error.
3. When feature negotiation fails, the socket should be marked as not usable,
so that the application is notified that an error occurs. This is achieved
by a new label, which uses an error code of `Aborted' and which sets the
socket state to CLOSED, as well as sk_err.
4. Avoids parsing the Ack twice in Respond state by not doing option processing
again in dccp_rcv_respond_partopen_state_process (as option processing has
already been done on the request_sock in dccp_check_req).
Since this addresses congestion-control initialisation, a corresponding
FIXME has been removed.
Signed-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>
Acked-by: Ian McDonald <ian.mcdonald@jandi.co.nz>
2008-09-04 05:30:19 +00: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 14:29:24 +00:00
|
|
|
if (dccp_parse_options(sk, NULL, skb))
|
dccp: Integration of dynamic feature activation - part 3 (client side)
This integrates feature-activation in the client, with these details:
1. When dccp_parse_options() fails, the reset code is already set, request_sent
_state_process() currently overrides this with `Packet Error', which is not
intended - so changed to use the reset code set in dccp_parse_options();
2. There was a FIXME to change the error code when dccp_ackvec_add() fails.
I have looked this up and found that:
* the check whether ackno < ISN is already made earlier,
* this Response is likely the 1st packet with an Ackno that the client gets,
* so when dccp_ackvec_add() fails, the reason is likely not a packet error.
3. When feature negotiation fails, the socket should be marked as not usable,
so that the application is notified that an error occurs. This is achieved
by a new label, which uses an error code of `Aborted' and which sets the
socket state to CLOSED, as well as sk_err.
4. Avoids parsing the Ack twice in Respond state by not doing option processing
again in dccp_rcv_respond_partopen_state_process (as option processing has
already been done on the request_sock in dccp_check_req).
Since this addresses congestion-control initialisation, a corresponding
FIXME has been removed.
Signed-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>
Acked-by: Ian McDonald <ian.mcdonald@jandi.co.nz>
2008-09-04 05:30:19 +00: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 01:43:56 +00:00
|
|
|
|
2007-09-26 05:40:44 +00:00
|
|
|
/* Obtain usec RTT sample from SYN exchange (used by CCID 3) */
|
|
|
|
|
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 18:27:17 +00:00
|
|
|
|
2008-08-19 04:14:20 +00: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 08:36:45 +00:00
|
|
|
/*
|
dccp: Fix the adjustments to AWL and SWL
This fixes a problem and a potential loophole with regard to seqno/ackno
validity: the problem is that the initial adjustments to AWL/SWL were
only performed at the begin of the connection, during the handshake.
Since the Sequence Window feature is always greater than Wmin=32 (7.5.2),
it is however necessary to perform these adjustments at least for the first
W/W' (variables as per 7.5.1) packets in the lifetime of a connection.
This requirement is complicated by the fact that W/W' can change at any time
during the lifetime of a connection.
Therefore the consequence is to perform this safety check each time SWL/AWL
are updated.
A second problem solved by this patch is that the remote/local Sequence Window
feature values (which set the bounds for AWL/SWL/SWH) are undefined until the
feature negotiation has completed.
During the initial handshake we have more stringent sequence number protection,
the changes added by this patch effect that {A,S}W{L,H} are within the correct
bounds at the instant that feature negotiation completes (since the SeqWin
feature activation handlers call dccp_update_gsr/gss()).
A detailed rationale is below -- can be removed from the commit message.
1. Server sequence number checks during initial handshake
---------------------------------------------------------
The server can not use the fields of the listening socket for seqno/ackno checks
and thus needs to store all relevant information on a per-connection basis on
the dccp_request socket. This is a size-constrained structure and has currently
only ISS (dreq_iss) and ISR (dreq_isr) defined.
Adding further fields (SW{L,H}, AW{L,H}) would increase the size of the struct
and it is questionable whether this will have any practical gain. The currently
implemented solution is as follows.
* receiving first Request: dccp_v{4,6}_conn_request sets
ISR := P.seqno, ISS := dccp_v{4,6}_init_sequence()
* sending first Response: dccp_v{4,6}_send_response via dccp_make_response()
sets P.seqno := ISS, sets P.ackno := ISR
* receiving retransmitted Request: dccp_check_req() overrides ISR := P.seqno
* answering retransmitted Request: dccp_make_response() sets ISS += 1,
otherwise as per first Response
* completing the handshake: succeeds in dccp_check_req() for the first Ack
where P.ackno == ISS (P.seqno is not tested)
* creating child socket: ISS, ISR are copied from the request_sock
This solution will succeed whenever the server can receive the Request and the
subsequent Ack in succession, without retransmissions. If there is packet loss,
the client needs to retransmit until this condition succeeds; it will otherwise
eventually give up. Adding further fields to the request_sock could increase
the robustness a bit, in that it would make possible to let a reordered Ack
(from a retransmitted Response) pass. The argument against such a solution is
that if the packet loss is not persistent and an Ack gets through, why not
wait for the one answering the original response: if the loss is persistent, it
is probably better to not start the connection in the first place.
Long story short: the present design (by Arnaldo) is simple and will likely work
just as well as a more complicated solution. As a consequence, {A,S}W{L,H} are
not needed until the moment the request_sock is cloned into the accept queue.
At that stage feature negotiation has completed, so that the values for the local
and remote Sequence Window feature (7.5.2) are known, i.e. we are now in a better
position to compute {A,S}W{L,H}.
2. Client sequence number checks during initial handshake
---------------------------------------------------------
Until entering PARTOPEN the client does not need the adjustments, since it
constrains the Ack window to the packet it sent.
* sending first Request: dccp_v{4,6}_connect() choose ISS,
dccp_connect() then sets GAR := ISS (as per 8.5),
dccp_transmit_skb() (with the previous bug fix) sets
GSS := ISS, AWL := ISS, AWH := GSS
* n-th retransmitted Request (with previous patch):
dccp_retransmit_skb() via timer calls
dccp_transmit_skb(), which sets GSS := ISS+n
and then AWL := ISS, AWH := ISS+n
* receiving any Response: dccp_rcv_request_sent_state_process()
-- accepts packet if AWL <= P.ackno <= AWH;
-- sets GSR = ISR = P.seqno
* sending the Ack completing the handshake: dccp_send_ack() calls
dccp_transmit_skb(), which sets GSS += 1
and AWL := ISS, AWH := GSS
Signed-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>
2008-09-04 05:30:19 +00: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 08:36:45 +00:00
|
|
|
*/
|
dccp: Fix the adjustments to AWL and SWL
This fixes a problem and a potential loophole with regard to seqno/ackno
validity: the problem is that the initial adjustments to AWL/SWL were
only performed at the begin of the connection, during the handshake.
Since the Sequence Window feature is always greater than Wmin=32 (7.5.2),
it is however necessary to perform these adjustments at least for the first
W/W' (variables as per 7.5.1) packets in the lifetime of a connection.
This requirement is complicated by the fact that W/W' can change at any time
during the lifetime of a connection.
Therefore the consequence is to perform this safety check each time SWL/AWL
are updated.
A second problem solved by this patch is that the remote/local Sequence Window
feature values (which set the bounds for AWL/SWL/SWH) are undefined until the
feature negotiation has completed.
During the initial handshake we have more stringent sequence number protection,
the changes added by this patch effect that {A,S}W{L,H} are within the correct
bounds at the instant that feature negotiation completes (since the SeqWin
feature activation handlers call dccp_update_gsr/gss()).
A detailed rationale is below -- can be removed from the commit message.
1. Server sequence number checks during initial handshake
---------------------------------------------------------
The server can not use the fields of the listening socket for seqno/ackno checks
and thus needs to store all relevant information on a per-connection basis on
the dccp_request socket. This is a size-constrained structure and has currently
only ISS (dreq_iss) and ISR (dreq_isr) defined.
Adding further fields (SW{L,H}, AW{L,H}) would increase the size of the struct
and it is questionable whether this will have any practical gain. The currently
implemented solution is as follows.
* receiving first Request: dccp_v{4,6}_conn_request sets
ISR := P.seqno, ISS := dccp_v{4,6}_init_sequence()
* sending first Response: dccp_v{4,6}_send_response via dccp_make_response()
sets P.seqno := ISS, sets P.ackno := ISR
* receiving retransmitted Request: dccp_check_req() overrides ISR := P.seqno
* answering retransmitted Request: dccp_make_response() sets ISS += 1,
otherwise as per first Response
* completing the handshake: succeeds in dccp_check_req() for the first Ack
where P.ackno == ISS (P.seqno is not tested)
* creating child socket: ISS, ISR are copied from the request_sock
This solution will succeed whenever the server can receive the Request and the
subsequent Ack in succession, without retransmissions. If there is packet loss,
the client needs to retransmit until this condition succeeds; it will otherwise
eventually give up. Adding further fields to the request_sock could increase
the robustness a bit, in that it would make possible to let a reordered Ack
(from a retransmitted Response) pass. The argument against such a solution is
that if the packet loss is not persistent and an Ack gets through, why not
wait for the one answering the original response: if the loss is persistent, it
is probably better to not start the connection in the first place.
Long story short: the present design (by Arnaldo) is simple and will likely work
just as well as a more complicated solution. As a consequence, {A,S}W{L,H} are
not needed until the moment the request_sock is cloned into the accept queue.
At that stage feature negotiation has completed, so that the values for the local
and remote Sequence Window feature (7.5.2) are known, i.e. we are now in a better
position to compute {A,S}W{L,H}.
2. Client sequence number checks during initial handshake
---------------------------------------------------------
Until entering PARTOPEN the client does not need the adjustments, since it
constrains the Ack window to the packet it sent.
* sending first Request: dccp_v{4,6}_connect() choose ISS,
dccp_connect() then sets GAR := ISS (as per 8.5),
dccp_transmit_skb() (with the previous bug fix) sets
GSS := ISS, AWL := ISS, AWH := GSS
* n-th retransmitted Request (with previous patch):
dccp_retransmit_skb() via timer calls
dccp_transmit_skb(), which sets GSS := ISS+n
and then AWL := ISS, AWH := ISS+n
* receiving any Response: dccp_rcv_request_sent_state_process()
-- accepts packet if AWL <= P.ackno <= AWH;
-- sets GSR = ISR = P.seqno
* sending the Ack completing the handshake: dccp_send_ack() calls
dccp_transmit_skb(), which sets GSS += 1
and AWL := ISS, AWH := GSS
Signed-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>
2008-09-04 05:30:19 +00:00
|
|
|
dp->dccps_gsr = dp->dccps_isr = DCCP_SKB_CB(skb)->dccpd_seq;
|
2005-08-10 03:14:34 +00:00
|
|
|
|
2005-12-14 07:26:10 +00:00
|
|
|
dccp_sync_mss(sk, icsk->icsk_pmtu_cookie);
|
2005-08-10 03:14:34 +00:00
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Step 10: Process REQUEST state (second part)
|
|
|
|
|
* If S.state == REQUEST,
|
2005-08-13 23:34:54 +00: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 03:14:34 +00:00
|
|
|
* S.state := PARTOPEN
|
|
|
|
|
* Set PARTOPEN timer
|
2006-12-10 18:01:18 +00:00
|
|
|
* Continue with S.state == PARTOPEN
|
2005-08-13 23:34:54 +00:00
|
|
|
* / * Step 12 will send the Ack completing the
|
|
|
|
|
* three-way handshake * /
|
2005-08-10 03:14:34 +00:00
|
|
|
*/
|
|
|
|
|
dccp_set_state(sk, DCCP_PARTOPEN);
|
|
|
|
|
|
dccp: Integration of dynamic feature activation - part 3 (client side)
This integrates feature-activation in the client, with these details:
1. When dccp_parse_options() fails, the reset code is already set, request_sent
_state_process() currently overrides this with `Packet Error', which is not
intended - so changed to use the reset code set in dccp_parse_options();
2. There was a FIXME to change the error code when dccp_ackvec_add() fails.
I have looked this up and found that:
* the check whether ackno < ISN is already made earlier,
* this Response is likely the 1st packet with an Ackno that the client gets,
* so when dccp_ackvec_add() fails, the reason is likely not a packet error.
3. When feature negotiation fails, the socket should be marked as not usable,
so that the application is notified that an error occurs. This is achieved
by a new label, which uses an error code of `Aborted' and which sets the
socket state to CLOSED, as well as sk_err.
4. Avoids parsing the Ack twice in Respond state by not doing option processing
again in dccp_rcv_respond_partopen_state_process (as option processing has
already been done on the request_sock in dccp_check_req).
Since this addresses congestion-control initialisation, a corresponding
FIXME has been removed.
Signed-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>
Acked-by: Ian McDonald <ian.mcdonald@jandi.co.nz>
2008-09-04 05:30:19 +00: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 03:14:34 +00:00
|
|
|
/* Make sure socket is routed, for correct metrics. */
|
2005-12-14 07:16:16 +00:00
|
|
|
icsk->icsk_af_ops->rebuild_header(sk);
|
2005-08-10 03:14:34 +00:00
|
|
|
|
|
|
|
|
if (!sock_flag(sk, SOCK_DEAD)) {
|
|
|
|
|
sk->sk_state_change(sk);
|
2007-11-26 12:10:50 +00:00
|
|
|
sk_wake_async(sk, SOCK_WAKE_IO, POLL_OUT);
|
2005-08-10 03:14:34 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (sk->sk_write_pending || icsk->icsk_ack.pingpong ||
|
|
|
|
|
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 18:01:18 +00:00
|
|
|
}
|
2005-08-10 03:14:34 +00:00
|
|
|
dccp_send_ack(sk);
|
|
|
|
|
return -1;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
out_invalid_packet:
|
2005-09-16 23:58:33 +00:00
|
|
|
/* dccp_v4_do_rcv will send a reset */
|
|
|
|
|
DCCP_SKB_CB(skb)->dccpd_reset_code = DCCP_RESET_CODE_PACKET_ERROR;
|
2006-12-10 18:01:18 +00:00
|
|
|
return 1;
|
dccp: Integration of dynamic feature activation - part 3 (client side)
This integrates feature-activation in the client, with these details:
1. When dccp_parse_options() fails, the reset code is already set, request_sent
_state_process() currently overrides this with `Packet Error', which is not
intended - so changed to use the reset code set in dccp_parse_options();
2. There was a FIXME to change the error code when dccp_ackvec_add() fails.
I have looked this up and found that:
* the check whether ackno < ISN is already made earlier,
* this Response is likely the 1st packet with an Ackno that the client gets,
* so when dccp_ackvec_add() fails, the reason is likely not a packet error.
3. When feature negotiation fails, the socket should be marked as not usable,
so that the application is notified that an error occurs. This is achieved
by a new label, which uses an error code of `Aborted' and which sets the
socket state to CLOSED, as well as sk_err.
4. Avoids parsing the Ack twice in Respond state by not doing option processing
again in dccp_rcv_respond_partopen_state_process (as option processing has
already been done on the request_sock in dccp_check_req).
Since this addresses congestion-control initialisation, a corresponding
FIXME has been removed.
Signed-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>
Acked-by: Ian McDonald <ian.mcdonald@jandi.co.nz>
2008-09-04 05:30:19 +00: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 03:14:34 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static int dccp_rcv_respond_partopen_state_process(struct sock *sk,
|
|
|
|
|
struct sk_buff *skb,
|
|
|
|
|
const struct dccp_hdr *dh,
|
|
|
|
|
const unsigned len)
|
|
|
|
|
{
|
|
|
|
|
int queued = 0;
|
|
|
|
|
|
|
|
|
|
switch (dh->dccph_type) {
|
|
|
|
|
case DCCP_PKT_RESET:
|
|
|
|
|
inet_csk_clear_xmit_timer(sk, ICSK_TIME_DACK);
|
|
|
|
|
break;
|
2005-10-11 04:25:00 +00:00
|
|
|
case DCCP_PKT_DATA:
|
|
|
|
|
if (sk->sk_state == DCCP_RESPOND)
|
|
|
|
|
break;
|
2005-08-10 03:14:34 +00:00
|
|
|
case DCCP_PKT_DATAACK:
|
|
|
|
|
case DCCP_PKT_ACK:
|
|
|
|
|
/*
|
2005-08-13 23:34:54 +00:00
|
|
|
* FIXME: we should be reseting the PARTOPEN (DELACK) timer
|
|
|
|
|
* 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 03:14:34 +00:00
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
/* Stop the PARTOPEN timer */
|
|
|
|
|
if (sk->sk_state == DCCP_PARTOPEN)
|
|
|
|
|
inet_csk_clear_xmit_timer(sk, ICSK_TIME_DACK);
|
|
|
|
|
|
|
|
|
|
dccp_sk(sk)->dccps_osr = DCCP_SKB_CB(skb)->dccpd_seq;
|
|
|
|
|
dccp_set_state(sk, DCCP_OPEN);
|
|
|
|
|
|
2005-10-11 04:25:00 +00:00
|
|
|
if (dh->dccph_type == DCCP_PKT_DATAACK ||
|
|
|
|
|
dh->dccph_type == DCCP_PKT_DATA) {
|
2006-01-03 22:25:17 +00:00
|
|
|
__dccp_rcv_established(sk, skb, dh, len);
|
2005-08-13 23:34:54 +00:00
|
|
|
queued = 1; /* packet was queued
|
2006-01-03 22:25:17 +00:00
|
|
|
(by __dccp_rcv_established) */
|
2005-08-10 03:14:34 +00:00
|
|
|
}
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return queued;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
int dccp_rcv_state_process(struct sock *sk, struct sk_buff *skb,
|
|
|
|
|
struct dccp_hdr *dh, unsigned len)
|
|
|
|
|
{
|
|
|
|
|
struct dccp_sock *dp = dccp_sk(sk);
|
2005-09-16 23:58:33 +00:00
|
|
|
struct dccp_skb_cb *dcb = DCCP_SKB_CB(skb);
|
2005-08-10 03:14:34 +00:00
|
|
|
const int old_state = sk->sk_state;
|
|
|
|
|
int queued = 0;
|
|
|
|
|
|
2005-08-13 23:36:01 +00:00
|
|
|
/*
|
|
|
|
|
* Step 3: Process LISTEN state
|
|
|
|
|
*
|
|
|
|
|
* If S.state == LISTEN,
|
2006-11-10 18:29:14 +00: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-13 23:36:01 +00:00
|
|
|
*/
|
|
|
|
|
if (sk->sk_state == DCCP_LISTEN) {
|
|
|
|
|
if (dh->dccph_type == DCCP_PKT_REQUEST) {
|
2005-12-14 07:16:16 +00:00
|
|
|
if (inet_csk(sk)->icsk_af_ops->conn_request(sk,
|
|
|
|
|
skb) < 0)
|
2005-08-13 23:36:01 +00:00
|
|
|
return 1;
|
|
|
|
|
goto discard;
|
|
|
|
|
}
|
|
|
|
|
if (dh->dccph_type == DCCP_PKT_RESET)
|
|
|
|
|
goto discard;
|
|
|
|
|
|
2005-09-16 23:58:33 +00:00
|
|
|
/* Caller (dccp_v4_do_rcv) will send Reset */
|
|
|
|
|
dcb->dccpd_reset_code = DCCP_RESET_CODE_NO_CONNECTION;
|
2005-08-13 23:36:01 +00:00
|
|
|
return 1;
|
|
|
|
|
}
|
|
|
|
|
|
dccp: Integration of dynamic feature activation - part 3 (client side)
This integrates feature-activation in the client, with these details:
1. When dccp_parse_options() fails, the reset code is already set, request_sent
_state_process() currently overrides this with `Packet Error', which is not
intended - so changed to use the reset code set in dccp_parse_options();
2. There was a FIXME to change the error code when dccp_ackvec_add() fails.
I have looked this up and found that:
* the check whether ackno < ISN is already made earlier,
* this Response is likely the 1st packet with an Ackno that the client gets,
* so when dccp_ackvec_add() fails, the reason is likely not a packet error.
3. When feature negotiation fails, the socket should be marked as not usable,
so that the application is notified that an error occurs. This is achieved
by a new label, which uses an error code of `Aborted' and which sets the
socket state to CLOSED, as well as sk_err.
4. Avoids parsing the Ack twice in Respond state by not doing option processing
again in dccp_rcv_respond_partopen_state_process (as option processing has
already been done on the request_sock in dccp_check_req).
Since this addresses congestion-control initialisation, a corresponding
FIXME has been removed.
Signed-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>
Acked-by: Ian McDonald <ian.mcdonald@jandi.co.nz>
2008-09-04 05:30:19 +00:00
|
|
|
if (sk->sk_state != DCCP_REQUESTING && sk->sk_state != DCCP_RESPOND) {
|
2005-08-10 03:14:34 +00:00
|
|
|
if (dccp_check_seqno(sk, skb))
|
|
|
|
|
goto discard;
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Step 8: Process options and mark acknowledgeable
|
|
|
|
|
*/
|
2007-12-13 14:29:24 +00:00
|
|
|
if (dccp_parse_options(sk, NULL, skb))
|
2008-08-23 11:28:27 +00:00
|
|
|
return 1;
|
2005-08-10 03:14:34 +00:00
|
|
|
|
2005-09-16 23:58:33 +00:00
|
|
|
if (dcb->dccpd_ack_seq != DCCP_PKT_WITHOUT_ACK_SEQ)
|
2005-08-10 03:14:34 +00:00
|
|
|
dccp_event_ack_recv(sk, skb);
|
|
|
|
|
|
dccp ccid-2: Phase out the use of boolean Ack Vector sysctl
This removes the use of the sysctl and the minisock variable for the Send Ack
Vector feature, which is now handled fully dynamically via feature negotiation;
i.e. when CCID2 is enabled, Ack Vectors are automatically enabled (as per
RFC 4341, 4.).
Using a sysctl in parallel to this implementation would open the door to
crashes, since much of the code relies on tests of the boolean minisock /
sysctl variable. Thus, this patch replaces all tests of type
if (dccp_msk(sk)->dccpms_send_ack_vector)
/* ... */
with
if (dp->dccps_hc_rx_ackvec != NULL)
/* ... */
The dccps_hc_rx_ackvec is allocated by the dccp_hdlr_ackvec() when feature
negotiation concluded that Ack Vectors are to be used on the half-connection.
Otherwise, it is NULL (due to dccp_init_sock/dccp_create_openreq_child),
so that the test is a valid one.
The activation handler for Ack Vectors is called as soon as the feature
negotiation has concluded at the
* server when the Ack marking the transition RESPOND => OPEN arrives;
* client after it has sent its ACK, marking the transition REQUEST => PARTOPEN.
Adding the sequence number of the Response packet to the Ack Vector has been
removed, since
(a) connection establishment implies that the Response has been received;
(b) the CCIDs only look at packets received in the (PART)OPEN state, i.e.
this entry will always be ignored;
(c) it can not be used for anything useful - to detect loss for instance, only
packets received after the loss can serve as pseudo-dupacks.
Signed-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>
Acked-by: Ian McDonald <ian.mcdonald@jandi.co.nz>
2008-09-04 05:30:19 +00:00
|
|
|
if (dp->dccps_hc_rx_ackvec != NULL &&
|
2005-09-18 07:17:51 +00:00
|
|
|
dccp_ackvec_add(dp->dccps_hc_rx_ackvec, sk,
|
dccp ccid-2: Ack Vector interface clean-up
This patch brings the Ack Vector interface up to date. Its main purpose is
to lay the basis for the subsequent patches of this set, which will use the
new data structure fields and routines.
There are no real algorithmic changes, rather an adaptation:
(1) Replaced the static Ack Vector size (2) with a #define so that it can
be adapted (with low loss / Ack Ratio, a value of 1 works, so 2 seems
to be sufficient for the moment) and added a solution so that computing
the ECN nonce will continue to work - even with larger Ack Vectors.
(2) Replaced the #defines for Ack Vector states with a complete enum.
(3) Replaced #defines to compute Ack Vector length and state with general
purpose routines (inlines), and updated code to use these.
(4) Added a `tail' field (conversion to circular buffer in subsequent patch).
(5) Updated the (outdated) documentation for Ack Vector struct.
(6) All sequence number containers now trimmed to 48 bits.
(7) Removal of unused bits:
* removed dccpav_ack_nonce from struct dccp_ackvec, since this is already
redundantly stored in the `dccpavr_ack_nonce' (of Ack Vector record);
* removed Elapsed Time for Ack Vectors (it was nowhere used);
* replaced semantics of dccpavr_sent_len with dccpavr_ack_runlen, since
the code needs to be able to remember the old run length;
* reduced the de-/allocation routines (redundant / duplicate tests).
Justification for removing Elapsed Time information [can be removed]:
---------------------------------------------------------------------
1. The Elapsed Time information for Ack Vectors was nowhere used in the code.
2. DCCP does not implement rate-based pacing of acknowledgments. The only
recommendation for always including Elapsed Time is in section 11.3 of
RFC 4340: "Receivers that rate-pace acknowledgements SHOULD [...]
include Elapsed Time options". But such is not the case here.
3. It does not really improve estimation accuracy. The Elapsed Time field only
records the time between the arrival of the last acknowledgeable packet and
the time the Ack Vector is sent out. Since Linux does not (yet) implement
delayed Acks, the time difference will typically be small, since often the
arrival of a data packet triggers sending feedback at the HC-receiver.
Justification for changes in de-/allocation routines [can be removed]:
----------------------------------------------------------------------
* INIT_LIST_HEAD in dccp_ackvec_record_new was redundant, since the list
pointers were later overwritten when the node was added via list_add();
* dccp_ackvec_record_new() was called in a single place only;
* calls to list_del_init() before calling dccp_ackvec_record_delete() were
redundant, since subsequently the entire element was k-freed;
* since all calls to dccp_ackvec_record_delete() were preceded to a call to
list_del_init(), the WARN_ON test would never evaluate to true;
* since all calls to dccp_ackvec_record_delete() were made from within
list_for_each_entry_safe(), the test for avr == NULL was redundant;
* list_empty() in ackvec_free was redundant, since the same condition is
embedded in the loop condition of the subsequent list_for_each_entry_safe().
Signed-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>
2008-09-04 05:30:19 +00:00
|
|
|
DCCP_SKB_CB(skb)->dccpd_seq, DCCPAV_RECEIVED))
|
2006-12-10 18:01:18 +00:00
|
|
|
goto discard;
|
2006-01-03 22:26:15 +00: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 11:56:48 +00:00
|
|
|
dccp_deliver_input_to_ccids(sk, skb);
|
2005-08-10 03:14:34 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Step 9: Process Reset
|
|
|
|
|
* If P.type == Reset,
|
|
|
|
|
* Tear down connection
|
|
|
|
|
* S.state := TIMEWAIT
|
|
|
|
|
* Set TIMEWAIT timer
|
|
|
|
|
* Drop packet and return
|
|
|
|
|
*/
|
|
|
|
|
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 12:27:48 +00:00
|
|
|
dccp_rcv_reset(sk, skb);
|
2005-08-10 03:14:34 +00:00
|
|
|
return 0;
|
|
|
|
|
/*
|
|
|
|
|
* Step 7: Check for unexpected packet types
|
2007-11-28 14:06:04 +00:00
|
|
|
* If (S.is_server and P.type == Response)
|
2005-08-10 03:14:34 +00:00
|
|
|
* 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
|
|
|
|
|
*/
|
|
|
|
|
} else if ((dp->dccps_role != DCCP_ROLE_CLIENT &&
|
2007-11-28 14:06:04 +00:00
|
|
|
dh->dccph_type == DCCP_PKT_RESPONSE) ||
|
2005-08-10 03:14:34 +00:00
|
|
|
(dp->dccps_role == DCCP_ROLE_CLIENT &&
|
|
|
|
|
dh->dccph_type == DCCP_PKT_REQUEST) ||
|
2005-08-13 23:34:54 +00:00
|
|
|
(sk->sk_state == DCCP_RESPOND &&
|
|
|
|
|
dh->dccph_type == DCCP_PKT_DATA)) {
|
2005-09-16 23:58:33 +00:00
|
|
|
dccp_send_sync(sk, dcb->dccpd_seq, DCCP_PKT_SYNC);
|
2005-08-10 03:14:34 +00:00
|
|
|
goto discard;
|
2005-08-24 04:50:06 +00:00
|
|
|
} else if (dh->dccph_type == 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 13:59:48 +00:00
|
|
|
if (dccp_rcv_closereq(sk, skb))
|
|
|
|
|
return 0;
|
2005-08-24 04:50:06 +00:00
|
|
|
goto discard;
|
|
|
|
|
} else if (dh->dccph_type == 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 13:59:48 +00:00
|
|
|
if (dccp_rcv_close(sk, skb))
|
|
|
|
|
return 0;
|
|
|
|
|
goto discard;
|
2005-08-10 03:14:34 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
switch (sk->sk_state) {
|
|
|
|
|
case DCCP_CLOSED:
|
2005-09-16 23:58:33 +00:00
|
|
|
dcb->dccpd_reset_code = DCCP_RESET_CODE_NO_CONNECTION;
|
2005-08-10 03:14:34 +00:00
|
|
|
return 1;
|
|
|
|
|
|
|
|
|
|
case DCCP_REQUESTING:
|
|
|
|
|
queued = dccp_rcv_request_sent_state_process(sk, skb, dh, len);
|
|
|
|
|
if (queued >= 0)
|
|
|
|
|
return queued;
|
|
|
|
|
|
|
|
|
|
__kfree_skb(skb);
|
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
|
|
case DCCP_RESPOND:
|
|
|
|
|
case DCCP_PARTOPEN:
|
2005-08-13 23:34:54 +00:00
|
|
|
queued = dccp_rcv_respond_partopen_state_process(sk, skb,
|
|
|
|
|
dh, len);
|
2005-08-10 03:14:34 +00:00
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
|
2005-08-13 23:34:54 +00:00
|
|
|
if (dh->dccph_type == DCCP_PKT_ACK ||
|
|
|
|
|
dh->dccph_type == DCCP_PKT_DATAACK) {
|
2005-08-10 03:14:34 +00:00
|
|
|
switch (old_state) {
|
|
|
|
|
case DCCP_PARTOPEN:
|
|
|
|
|
sk->sk_state_change(sk);
|
2007-11-26 12:10:50 +00:00
|
|
|
sk_wake_async(sk, SOCK_WAKE_IO, POLL_OUT);
|
2005-08-10 03:14:34 +00:00
|
|
|
break;
|
|
|
|
|
}
|
2007-09-26 13:30:05 +00: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 03:14:34 +00:00
|
|
|
}
|
|
|
|
|
|
2006-12-10 18:01:18 +00:00
|
|
|
if (!queued) {
|
2005-08-10 03:14:34 +00:00
|
|
|
discard:
|
|
|
|
|
__kfree_skb(skb);
|
|
|
|
|
}
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
2005-12-14 07:24:16 +00:00
|
|
|
|
|
|
|
|
EXPORT_SYMBOL_GPL(dccp_rcv_state_process);
|
2007-03-20 18:23:18 +00:00
|
|
|
|
|
|
|
|
/**
|
2007-09-26 05:40:44 +00:00
|
|
|
* dccp_sample_rtt - Validate and finalise computation of RTT sample
|
|
|
|
|
* @delta: number of microseconds between packet and acknowledgment
|
|
|
|
|
* 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 18:23:18 +00:00
|
|
|
*/
|
2007-09-26 05:40:44 +00:00
|
|
|
u32 dccp_sample_rtt(struct sock *sk, long delta)
|
2007-03-20 18:23:18 +00:00
|
|
|
{
|
2007-09-26 05:40:44 +00: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 18:23:18 +00:00
|
|
|
|
|
|
|
|
if (unlikely(delta <= 0)) {
|
2007-09-26 05:40:44 +00:00
|
|
|
DCCP_WARN("unusable RTT sample %ld, using min\n", delta);
|
2007-03-20 18:23:18 +00:00
|
|
|
return DCCP_SANE_RTT_MIN;
|
|
|
|
|
}
|
2007-09-26 05:40:44 +00:00
|
|
|
if (unlikely(delta > DCCP_SANE_RTT_MAX)) {
|
|
|
|
|
DCCP_WARN("RTT sample %ld too large, using max\n", delta);
|
2007-03-20 18:23:18 +00:00
|
|
|
return DCCP_SANE_RTT_MAX;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return delta;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
EXPORT_SYMBOL_GPL(dccp_sample_rtt);
|
