aboutsummaryrefslogtreecommitdiffstats
path: root/net/dccp/output.c
diff options
context:
space:
mode:
authorGerrit Renker <gerrit@erg.abdn.ac.uk>2008-11-12 03:48:44 -0500
committerDavid S. Miller <davem@davemloft.net>2008-11-12 03:48:44 -0500
commit9eca0a47dee201a73967026985b5f0a79a46bd36 (patch)
treebeb39fbd3c28865705d7409aa35fd59914257da9 /net/dccp/output.c
parentd90ebcbfa7f5a8b4e20518c9f94c5c4e4cd3c2e5 (diff)
dccp: Resolve dependencies of features on choice of CCID
This provides a missing link in the code chain, as several features implicitly depend and/or rely on the choice of CCID. Most notably, this is the Send Ack Vector feature, but also Ack Ratio and Send Loss Event Rate (also taken care of). For Send Ack Vector, the situation is as follows: * since CCID2 mandates the use of Ack Vectors, there is no point in allowing endpoints which use CCID2 to disable Ack Vector features such a connection; * a peer with a TX CCID of CCID2 will always expect Ack Vectors, and a peer with a RX CCID of CCID2 must always send Ack Vectors (RFC 4341, sec. 4); * for all other CCIDs, the use of (Send) Ack Vector is optional and thus negotiable. However, this implies that the code negotiating the use of Ack Vectors also supports it (i.e. is able to supply and to either parse or ignore received Ack Vectors). Since this is not the case (CCID-3 has no Ack Vector support), the use of Ack Vectors is here disabled, with a comment in the source code. An analogous consideration arises for the Send Loss Event Rate feature, since the CCID-3 implementation does not support the loss interval options of RFC 4342. To make such use explicit, corresponding feature-negotiation options are inserted which signal the use of the loss event rate option, as it is used by the CCID3 code. Lastly, the values of the Ack Ratio feature are matched to the choice of CCID. The patch implements this as a function which is called after the user has made all other registrations for changing default values of features. The table is variable-length, the reserved (and hence for feature-negotiation invalid, confirmed by considering section 19.4 of RFC 4340) feature number `0' is used to mark the end of the table. Signed-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk> Acked-by: Ian McDonald <ian.mcdonald@jandi.co.nz> Signed-off-by: David S. Miller <davem@davemloft.net>
Diffstat (limited to 'net/dccp/output.c')
-rw-r--r--net/dccp/output.c4
1 files changed, 4 insertions, 0 deletions
diff --git a/net/dccp/output.c b/net/dccp/output.c
index 809d803d5006..92f3f6f2ef51 100644
--- a/net/dccp/output.c
+++ b/net/dccp/output.c
@@ -469,6 +469,10 @@ int dccp_connect(struct sock *sk)
469 struct sk_buff *skb; 469 struct sk_buff *skb;
470 struct inet_connection_sock *icsk = inet_csk(sk); 470 struct inet_connection_sock *icsk = inet_csk(sk);
471 471
472 /* do not connect if feature negotiation setup fails */
473 if (dccp_feat_finalise_settings(dccp_sk(sk)))
474 return -EPROTO;
475
472 dccp_connect_init(sk); 476 dccp_connect_init(sk);
473 477
474 skb = alloc_skb(sk->sk_prot->max_header, sk->sk_allocation); 478 skb = alloc_skb(sk->sk_prot->max_header, sk->sk_allocation);