2005-08-09 20:14:34 -07:00
|
|
|
#ifndef _DCCP_H
|
|
|
|
|
#define _DCCP_H
|
|
|
|
|
/*
|
|
|
|
|
* net/dccp/dccp.h
|
|
|
|
|
*
|
|
|
|
|
* An implementation of the DCCP protocol
|
2005-08-20 00:23:43 -03:00
|
|
|
* Copyright (c) 2005 Arnaldo Carvalho de Melo <acme@conectiva.com.br>
|
2006-08-26 19:01:30 -07:00
|
|
|
* Copyright (c) 2005-6 Ian McDonald <ian.mcdonald@jandi.co.nz>
|
2005-08-09 20:14:34 -07:00
|
|
|
*
|
|
|
|
|
* This program is free software; you can redistribute it and/or modify it
|
|
|
|
|
* under the terms of the GNU General Public License version 2 as
|
|
|
|
|
* published by the Free Software Foundation.
|
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
#include <linux/dccp.h>
|
2007-08-19 17:16:35 -07:00
|
|
|
#include <linux/ktime.h>
|
2005-08-09 20:14:34 -07:00
|
|
|
#include <net/snmp.h>
|
|
|
|
|
#include <net/sock.h>
|
|
|
|
|
#include <net/tcp.h>
|
2005-09-18 00:17:51 -07:00
|
|
|
#include "ackvec.h"
|
2005-08-09 20:14:34 -07:00
|
|
|
|
2006-11-20 18:39:23 -02:00
|
|
|
/*
|
|
|
|
|
* DCCP - specific warning and debugging macros.
|
|
|
|
|
*/
|
|
|
|
|
#define DCCP_WARN(fmt, a...) LIMIT_NETDEBUG(KERN_WARNING "%s: " fmt, \
|
2008-03-05 20:47:47 -08:00
|
|
|
__func__, ##a)
|
2006-11-20 18:39:23 -02:00
|
|
|
#define DCCP_CRIT(fmt, a...) printk(KERN_CRIT fmt " at %s:%d/%s()\n", ##a, \
|
2008-03-05 20:47:47 -08:00
|
|
|
__FILE__, __LINE__, __func__)
|
2006-11-20 18:39:23 -02:00
|
|
|
#define DCCP_BUG(a...) do { DCCP_CRIT("BUG: " a); dump_stack(); } while(0)
|
|
|
|
|
#define DCCP_BUG_ON(cond) do { if (unlikely((cond) != 0)) \
|
|
|
|
|
DCCP_BUG("\"%s\" holds (exception!)", \
|
|
|
|
|
__stringify(cond)); \
|
2006-11-15 21:27:47 -02:00
|
|
|
} while (0)
|
|
|
|
|
|
2006-11-20 18:26:03 -02:00
|
|
|
#define DCCP_PRINTK(enable, fmt, args...) do { if (enable) \
|
|
|
|
|
printk(fmt, ##args); \
|
2007-02-09 23:24:38 +09:00
|
|
|
} while(0)
|
2006-11-20 18:26:03 -02:00
|
|
|
#define DCCP_PR_DEBUG(enable, fmt, a...) DCCP_PRINTK(enable, KERN_DEBUG \
|
2008-03-05 20:47:47 -08:00
|
|
|
"%s: " fmt, __func__, ##a)
|
2006-11-20 18:26:03 -02:00
|
|
|
|
2005-08-13 20:35:39 -03:00
|
|
|
#ifdef CONFIG_IP_DCCP_DEBUG
|
2005-08-09 20:14:34 -07:00
|
|
|
extern int dccp_debug;
|
2006-11-20 18:26:03 -02:00
|
|
|
#define dccp_pr_debug(format, a...) DCCP_PR_DEBUG(dccp_debug, format, ##a)
|
|
|
|
|
#define dccp_pr_debug_cat(format, a...) DCCP_PRINTK(dccp_debug, format, ##a)
|
2008-09-04 07:30:19 +02:00
|
|
|
#define dccp_debug(fmt, a...) dccp_pr_debug_cat(KERN_DEBUG fmt, ##a)
|
2005-08-09 20:14:34 -07:00
|
|
|
#else
|
|
|
|
|
#define dccp_pr_debug(format, a...)
|
|
|
|
|
#define dccp_pr_debug_cat(format, a...)
|
2008-09-04 07:30:19 +02:00
|
|
|
#define dccp_debug(format, a...)
|
2005-08-09 20:14:34 -07:00
|
|
|
#endif
|
|
|
|
|
|
|
|
|
|
extern struct inet_hashinfo dccp_hashinfo;
|
|
|
|
|
|
|
|
|
|
extern atomic_t dccp_orphan_count;
|
|
|
|
|
|
|
|
|
|
extern void dccp_time_wait(struct sock *sk, int state, int timeo);
|
|
|
|
|
|
2006-11-10 02:13:56 -02:00
|
|
|
/*
|
|
|
|
|
* Set safe upper bounds for header and option length. Since Data Offset is 8
|
|
|
|
|
* bits (RFC 4340, sec. 5.1), the total header length can never be more than
|
|
|
|
|
* 4 * 255 = 1020 bytes. The largest possible header length is 28 bytes (X=1):
|
|
|
|
|
* - DCCP-Response with ACK Subheader and 4 bytes of Service code OR
|
|
|
|
|
* - DCCP-Reset with ACK Subheader and 4 bytes of Reset Code fields
|
|
|
|
|
* Hence a safe upper bound for the maximum option length is 1020-28 = 992
|
|
|
|
|
*/
|
2008-09-04 07:30:19 +02:00
|
|
|
#define MAX_DCCP_SPECIFIC_HEADER (255 * sizeof(uint32_t))
|
2006-11-10 02:13:56 -02:00
|
|
|
#define DCCP_MAX_PACKET_HDR 28
|
|
|
|
|
#define DCCP_MAX_OPT_LEN (MAX_DCCP_SPECIFIC_HEADER - DCCP_MAX_PACKET_HDR)
|
|
|
|
|
#define MAX_DCCP_HEADER (MAX_DCCP_SPECIFIC_HEADER + MAX_HEADER)
|
2005-08-09 20:14:34 -07:00
|
|
|
|
2008-09-04 07:30:19 +02:00
|
|
|
/* Upper bound for initial feature-negotiation overhead (padded to 32 bits) */
|
|
|
|
|
#define DCCP_FEATNEG_OVERHEAD (32 * sizeof(uint32_t))
|
|
|
|
|
|
2005-08-09 20:14:34 -07:00
|
|
|
#define DCCP_TIMEWAIT_LEN (60 * HZ) /* how long to wait to destroy TIME-WAIT
|
|
|
|
|
* state, about 60 seconds */
|
|
|
|
|
|
2006-10-24 16:17:51 -07:00
|
|
|
/* RFC 1122, 4.2.3.1 initial RTO value */
|
2005-08-09 20:14:34 -07:00
|
|
|
#define DCCP_TIMEOUT_INIT ((unsigned)(3 * HZ))
|
|
|
|
|
|
2007-12-13 12:16:23 -02:00
|
|
|
/*
|
|
|
|
|
* The maximum back-off value for retransmissions. This is needed for
|
|
|
|
|
* - retransmitting client-Requests (sec. 8.1.1),
|
|
|
|
|
* - retransmitting Close/CloseReq when closing (sec. 8.3),
|
|
|
|
|
* - feature-negotiation retransmission (sec. 6.6.3),
|
|
|
|
|
* - Acks in client-PARTOPEN state (sec. 8.1.5).
|
|
|
|
|
*/
|
|
|
|
|
#define DCCP_RTO_MAX ((unsigned)(64 * HZ))
|
2007-03-20 15:23:18 -03:00
|
|
|
|
2008-09-04 07:30:19 +02:00
|
|
|
/* DCCP base time resolution - 10 microseconds (RFC 4340, 13.1 ... 13.3) */
|
|
|
|
|
#define DCCP_TIME_RESOLUTION 10
|
|
|
|
|
|
2007-12-12 14:06:14 -02:00
|
|
|
/*
|
|
|
|
|
* RTT sampling: sanity bounds and fallback RTT value from RFC 4340, section 3.4
|
|
|
|
|
*/
|
2008-09-04 07:30:19 +02:00
|
|
|
#define DCCP_SANE_RTT_MIN (10 * DCCP_TIME_RESOLUTION)
|
2007-12-12 14:06:14 -02:00
|
|
|
#define DCCP_FALLBACK_RTT (USEC_PER_SEC / 5)
|
|
|
|
|
#define DCCP_SANE_RTT_MAX (3 * USEC_PER_SEC)
|
2007-03-20 15:23:18 -03:00
|
|
|
|
2005-08-09 20:14:34 -07:00
|
|
|
/* Maximal interval between probes for local resources. */
|
|
|
|
|
#define DCCP_RESOURCE_PROBE_INTERVAL ((unsigned)(HZ / 2U))
|
|
|
|
|
|
2006-11-13 13:23:52 -02:00
|
|
|
/* sysctl variables for DCCP */
|
|
|
|
|
extern int sysctl_dccp_request_retries;
|
|
|
|
|
extern int sysctl_dccp_retries1;
|
|
|
|
|
extern int sysctl_dccp_retries2;
|
2006-11-20 18:30:17 -02:00
|
|
|
extern int sysctl_dccp_tx_qlen;
|
2007-09-26 11:31:49 -03:00
|
|
|
extern int sysctl_dccp_sync_ratelimit;
|
2006-11-13 13:23:52 -02:00
|
|
|
|
2007-03-20 12:26:51 -03:00
|
|
|
/*
|
|
|
|
|
* 48-bit sequence number arithmetic (signed and unsigned)
|
|
|
|
|
*/
|
|
|
|
|
#define INT48_MIN 0x800000000000LL /* 2^47 */
|
|
|
|
|
#define UINT48_MAX 0xFFFFFFFFFFFFLL /* 2^48 - 1 */
|
|
|
|
|
#define COMPLEMENT48(x) (0x1000000000000LL - (x)) /* 2^48 - x */
|
|
|
|
|
#define TO_SIGNED48(x) (((x) < INT48_MIN)? (x) : -COMPLEMENT48( (x)))
|
|
|
|
|
#define TO_UNSIGNED48(x) (((x) >= 0)? (x) : COMPLEMENT48(-(x)))
|
|
|
|
|
#define ADD48(a, b) (((a) + (b)) & UINT48_MAX)
|
|
|
|
|
#define SUB48(a, b) ADD48((a), COMPLEMENT48(b))
|
|
|
|
|
|
|
|
|
|
static inline void dccp_set_seqno(u64 *seqno, u64 value)
|
|
|
|
|
{
|
|
|
|
|
*seqno = value & UINT48_MAX;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static inline void dccp_inc_seqno(u64 *seqno)
|
|
|
|
|
{
|
|
|
|
|
*seqno = ADD48(*seqno, 1);
|
|
|
|
|
}
|
|
|
|
|
|
2007-03-20 12:45:59 -03:00
|
|
|
/* signed mod-2^48 distance: pos. if seqno1 < seqno2, neg. if seqno1 > seqno2 */
|
|
|
|
|
static inline s64 dccp_delta_seqno(const u64 seqno1, const u64 seqno2)
|
2007-03-20 12:26:51 -03:00
|
|
|
{
|
2007-03-20 12:45:59 -03:00
|
|
|
u64 delta = SUB48(seqno2, seqno1);
|
|
|
|
|
|
|
|
|
|
return TO_SIGNED48(delta);
|
2007-03-20 12:26:51 -03:00
|
|
|
}
|
|
|
|
|
|
2005-08-09 20:14:34 -07:00
|
|
|
/* is seq1 < seq2 ? */
|
2005-08-14 21:05:53 -03:00
|
|
|
static inline int before48(const u64 seq1, const u64 seq2)
|
2005-08-09 20:14:34 -07:00
|
|
|
{
|
2007-03-20 13:00:26 -03:00
|
|
|
return (s64)((seq2 << 16) - (seq1 << 16)) > 0;
|
2005-08-09 20:14:34 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* is seq1 > seq2 ? */
|
2007-03-20 13:00:26 -03:00
|
|
|
#define after48(seq1, seq2) before48(seq2, seq1)
|
2005-08-09 20:14:34 -07:00
|
|
|
|
|
|
|
|
/* is seq2 <= seq1 <= seq3 ? */
|
2005-08-14 21:05:53 -03:00
|
|
|
static inline int between48(const u64 seq1, const u64 seq2, const u64 seq3)
|
2005-08-09 20:14:34 -07:00
|
|
|
{
|
|
|
|
|
return (seq3 << 16) - (seq2 << 16) >= (seq1 << 16) - (seq2 << 16);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static inline u64 max48(const u64 seq1, const u64 seq2)
|
|
|
|
|
{
|
|
|
|
|
return after48(seq1, seq2) ? seq1 : seq2;
|
|
|
|
|
}
|
|
|
|
|
|
2008-07-13 11:51:40 +01:00
|
|
|
/**
|
|
|
|
|
* dccp_loss_free - Evaluates condition for data loss from RFC 4340, 7.7.1
|
|
|
|
|
* @s1: start sequence number
|
|
|
|
|
* @s2: end sequence number
|
|
|
|
|
* @ndp: NDP count on packet with sequence number @s2
|
|
|
|
|
* Returns true if the sequence range s1...s2 has no data loss.
|
|
|
|
|
*/
|
|
|
|
|
static inline bool dccp_loss_free(const u64 s1, const u64 s2, const u64 ndp)
|
|
|
|
|
{
|
|
|
|
|
s64 delta = dccp_delta_seqno(s1, s2);
|
|
|
|
|
|
2008-07-25 21:43:18 -07:00
|
|
|
WARN_ON(delta < 0);
|
2008-07-13 11:51:40 +01:00
|
|
|
return (u64)delta <= ndp + 1;
|
|
|
|
|
}
|
|
|
|
|
|
2005-08-09 20:14:34 -07:00
|
|
|
enum {
|
|
|
|
|
DCCP_MIB_NUM = 0,
|
|
|
|
|
DCCP_MIB_ACTIVEOPENS, /* ActiveOpens */
|
|
|
|
|
DCCP_MIB_ESTABRESETS, /* EstabResets */
|
|
|
|
|
DCCP_MIB_CURRESTAB, /* CurrEstab */
|
2007-02-09 23:24:38 +09:00
|
|
|
DCCP_MIB_OUTSEGS, /* OutSegs */
|
2005-08-09 20:14:34 -07:00
|
|
|
DCCP_MIB_OUTRSTS,
|
|
|
|
|
DCCP_MIB_ABORTONTIMEOUT,
|
|
|
|
|
DCCP_MIB_TIMEOUTS,
|
|
|
|
|
DCCP_MIB_ABORTFAILED,
|
|
|
|
|
DCCP_MIB_PASSIVEOPENS,
|
|
|
|
|
DCCP_MIB_ATTEMPTFAILS,
|
|
|
|
|
DCCP_MIB_OUTDATAGRAMS,
|
|
|
|
|
DCCP_MIB_INERRS,
|
|
|
|
|
DCCP_MIB_OPTMANDATORYERROR,
|
|
|
|
|
DCCP_MIB_INVALIDOPT,
|
|
|
|
|
__DCCP_MIB_MAX
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
#define DCCP_MIB_MAX __DCCP_MIB_MAX
|
|
|
|
|
struct dccp_mib {
|
|
|
|
|
unsigned long mibs[DCCP_MIB_MAX];
|
|
|
|
|
} __SNMP_MIB_ALIGN__;
|
|
|
|
|
|
|
|
|
|
DECLARE_SNMP_STAT(struct dccp_mib, dccp_statistics);
|
2005-08-13 20:34:54 -03:00
|
|
|
#define DCCP_INC_STATS(field) SNMP_INC_STATS(dccp_statistics, field)
|
|
|
|
|
#define DCCP_INC_STATS_BH(field) SNMP_INC_STATS_BH(dccp_statistics, field)
|
|
|
|
|
#define DCCP_INC_STATS_USER(field) SNMP_INC_STATS_USER(dccp_statistics, field)
|
|
|
|
|
#define DCCP_DEC_STATS(field) SNMP_DEC_STATS(dccp_statistics, field)
|
|
|
|
|
#define DCCP_ADD_STATS_BH(field, val) \
|
|
|
|
|
SNMP_ADD_STATS_BH(dccp_statistics, field, val)
|
|
|
|
|
#define DCCP_ADD_STATS_USER(field, val) \
|
|
|
|
|
SNMP_ADD_STATS_USER(dccp_statistics, field, val)
|
2005-08-09 20:14:34 -07:00
|
|
|
|
2006-11-10 17:43:06 -02:00
|
|
|
/*
|
|
|
|
|
* Checksumming routines
|
|
|
|
|
*/
|
2007-05-28 16:32:26 -03:00
|
|
|
static inline unsigned int dccp_csum_coverage(const struct sk_buff *skb)
|
2006-11-10 17:43:06 -02:00
|
|
|
{
|
|
|
|
|
const struct dccp_hdr* dh = dccp_hdr(skb);
|
|
|
|
|
|
|
|
|
|
if (dh->dccph_cscov == 0)
|
|
|
|
|
return skb->len;
|
|
|
|
|
return (dh->dccph_doff + dh->dccph_cscov - 1) * sizeof(u32);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static inline void dccp_csum_outgoing(struct sk_buff *skb)
|
|
|
|
|
{
|
2007-05-28 16:32:26 -03:00
|
|
|
unsigned int cov = dccp_csum_coverage(skb);
|
2006-11-10 17:43:06 -02:00
|
|
|
|
|
|
|
|
if (cov >= skb->len)
|
|
|
|
|
dccp_hdr(skb)->dccph_cscov = 0;
|
|
|
|
|
|
|
|
|
|
skb->csum = skb_checksum(skb, 0, (cov > skb->len)? skb->len : cov, 0);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
extern void dccp_v4_send_check(struct sock *sk, int len, struct sk_buff *skb);
|
|
|
|
|
|
2008-07-26 11:59:09 +01:00
|
|
|
extern int dccp_retransmit_skb(struct sock *sk);
|
2005-08-09 20:14:34 -07:00
|
|
|
|
|
|
|
|
extern void dccp_send_ack(struct sock *sk);
|
2008-08-06 23:50:04 -07:00
|
|
|
extern void dccp_reqsk_send_ack(struct sock *sk, struct sk_buff *skb,
|
|
|
|
|
struct request_sock *rsk);
|
2006-11-10 12:32:01 -02:00
|
|
|
|
2005-08-17 03:10:59 -03:00
|
|
|
extern void dccp_send_sync(struct sock *sk, const u64 seq,
|
|
|
|
|
const enum dccp_pkt_type pkt_type);
|
2005-08-09 20:14:34 -07:00
|
|
|
|
2008-09-04 07:30:19 +02:00
|
|
|
/*
|
|
|
|
|
* TX Packet Dequeueing Interface
|
|
|
|
|
*/
|
|
|
|
|
extern void dccp_qpolicy_push(struct sock *sk, struct sk_buff *skb);
|
|
|
|
|
extern bool dccp_qpolicy_full(struct sock *sk);
|
|
|
|
|
extern void dccp_qpolicy_drop(struct sock *sk, struct sk_buff *skb);
|
|
|
|
|
extern struct sk_buff *dccp_qpolicy_top(struct sock *sk);
|
|
|
|
|
extern struct sk_buff *dccp_qpolicy_pop(struct sock *sk);
|
2008-09-04 07:30:19 +02:00
|
|
|
extern bool dccp_qpolicy_param_ok(struct sock *sk, __be32 param);
|
2008-09-04 07:30:19 +02:00
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* TX Packet Output and TX Timers
|
|
|
|
|
*/
|
dccp: Refine the wait-for-ccid mechanism
This extends the existing wait-for-ccid routine so that it may be used with
different types of CCID. It further addresses the problems listed below.
The code looks if the write queue is non-empty and grants the TX CCID up to
`timeout' jiffies to drain the queue. It will instead purge that queue if
* the delay suggested by the CCID exceeds the time budget;
* a socket error occurred while waiting for the CCID;
* there is a signal pending (eg. annoyed user pressed Control-C);
* the CCID does not support delays (we don't know how long it will take).
D e t a i l s [can be removed]
-------------------------------
DCCP's sending mechanism functions a bit like non-blocking I/O: dccp_sendmsg()
will enqueue up to net.dccp.default.tx_qlen packets (default=5), without waiting
for them to be released to the network.
Rate-based CCIDs, such as CCID3/4, can impose sending delays of up to maximally
64 seconds (t_mbi in RFC 3448). Hence the write queue may still contain packets
when the application closes. Since the write queue is congestion-controlled by
the CCID, draining the queue is also under control of the CCID.
There are several problems that needed to be addressed:
1) The queue-drain mechanism only works with rate-based CCIDs. If CCID2 for
example has a full TX queue and becomes network-limited just as the
application wants to close, then waiting for CCID2 to become unblocked could
lead to an indefinite delay (i.e., application "hangs").
2) Since each TX CCID in turn uses a feedback mechanism, there may be changes
in its sending policy while the queue is being drained. This can lead to
further delays during which the application will not be able to terminate.
3) The minimum wait time for CCID3/4 can be expected to be the queue length
times the current inter-packet delay. For example if tx_qlen=100 and a delay
of 15 ms is used for each packet, then the application would have to wait
for a minimum of 1.5 seconds before being allowed to exit.
4) There is no way for the user/application to control this behaviour. It would
be good to use the timeout argument of dccp_close() as an upper bound. Then
the maximum time that an application is willing to wait for its CCIDs to can
be set via the SO_LINGER option.
These problems are addressed by giving the CCID a grace period of up to the
`timeout' value.
The wait-for-ccid function is, as before, used when the application
(a) has read all the data in its receive buffer and
(b) if SO_LINGER was set with a non-zero linger time, or
(c) the socket is either in the OPEN (active close) or in the PASSIVE_CLOSEREQ
state (client application closes after receiving CloseReq).
In addition, there is a catch-all case by calling __skb_queue_purge() after
waiting for the CCID. This is necessary since the write queue may still have
data when
(a) the host has been passively-closed,
(b) abnormal termination (unread data, zero linger time),
(c) wait-for-ccid could not finish within the given time limit.
Signed-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>
2008-09-04 07:30:19 +02:00
|
|
|
extern void dccp_write_xmit(struct sock *sk);
|
2005-08-29 02:15:54 -03:00
|
|
|
extern void dccp_write_space(struct sock *sk);
|
dccp: Refine the wait-for-ccid mechanism
This extends the existing wait-for-ccid routine so that it may be used with
different types of CCID. It further addresses the problems listed below.
The code looks if the write queue is non-empty and grants the TX CCID up to
`timeout' jiffies to drain the queue. It will instead purge that queue if
* the delay suggested by the CCID exceeds the time budget;
* a socket error occurred while waiting for the CCID;
* there is a signal pending (eg. annoyed user pressed Control-C);
* the CCID does not support delays (we don't know how long it will take).
D e t a i l s [can be removed]
-------------------------------
DCCP's sending mechanism functions a bit like non-blocking I/O: dccp_sendmsg()
will enqueue up to net.dccp.default.tx_qlen packets (default=5), without waiting
for them to be released to the network.
Rate-based CCIDs, such as CCID3/4, can impose sending delays of up to maximally
64 seconds (t_mbi in RFC 3448). Hence the write queue may still contain packets
when the application closes. Since the write queue is congestion-controlled by
the CCID, draining the queue is also under control of the CCID.
There are several problems that needed to be addressed:
1) The queue-drain mechanism only works with rate-based CCIDs. If CCID2 for
example has a full TX queue and becomes network-limited just as the
application wants to close, then waiting for CCID2 to become unblocked could
lead to an indefinite delay (i.e., application "hangs").
2) Since each TX CCID in turn uses a feedback mechanism, there may be changes
in its sending policy while the queue is being drained. This can lead to
further delays during which the application will not be able to terminate.
3) The minimum wait time for CCID3/4 can be expected to be the queue length
times the current inter-packet delay. For example if tx_qlen=100 and a delay
of 15 ms is used for each packet, then the application would have to wait
for a minimum of 1.5 seconds before being allowed to exit.
4) There is no way for the user/application to control this behaviour. It would
be good to use the timeout argument of dccp_close() as an upper bound. Then
the maximum time that an application is willing to wait for its CCIDs to can
be set via the SO_LINGER option.
These problems are addressed by giving the CCID a grace period of up to the
`timeout' value.
The wait-for-ccid function is, as before, used when the application
(a) has read all the data in its receive buffer and
(b) if SO_LINGER was set with a non-zero linger time, or
(c) the socket is either in the OPEN (active close) or in the PASSIVE_CLOSEREQ
state (client application closes after receiving CloseReq).
In addition, there is a catch-all case by calling __skb_queue_purge() after
waiting for the CCID. This is necessary since the write queue may still have
data when
(a) the host has been passively-closed,
(b) abnormal termination (unread data, zero linger time),
(c) wait-for-ccid could not finish within the given time limit.
Signed-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>
2008-09-04 07:30:19 +02:00
|
|
|
extern void dccp_flush_write_queue(struct sock *sk, long *time_budget);
|
2005-08-09 20:30:56 -07:00
|
|
|
|
2005-08-09 20:14:34 -07:00
|
|
|
extern void dccp_init_xmit_timers(struct sock *sk);
|
|
|
|
|
static inline void dccp_clear_xmit_timers(struct sock *sk)
|
|
|
|
|
{
|
|
|
|
|
inet_csk_clear_xmit_timers(sk);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
extern unsigned int dccp_sync_mss(struct sock *sk, u32 pmtu);
|
|
|
|
|
|
|
|
|
|
extern const char *dccp_packet_name(const int type);
|
|
|
|
|
extern const char *dccp_state_name(const int state);
|
|
|
|
|
|
2006-03-20 21:58:56 -08:00
|
|
|
extern void dccp_set_state(struct sock *sk, const int state);
|
|
|
|
|
extern void dccp_done(struct sock *sk);
|
2005-08-09 20:14:34 -07:00
|
|
|
|
2008-09-04 07:30:19 +02:00
|
|
|
extern int dccp_reqsk_init(struct request_sock *rq, struct dccp_sock const *dp,
|
|
|
|
|
struct sk_buff const *skb);
|
2005-08-09 20:14:34 -07:00
|
|
|
|
|
|
|
|
extern int dccp_v4_conn_request(struct sock *sk, struct sk_buff *skb);
|
|
|
|
|
|
|
|
|
|
extern struct sock *dccp_create_openreq_child(struct sock *sk,
|
|
|
|
|
const struct request_sock *req,
|
|
|
|
|
const struct sk_buff *skb);
|
|
|
|
|
|
|
|
|
|
extern int dccp_v4_do_rcv(struct sock *sk, struct sk_buff *skb);
|
|
|
|
|
|
|
|
|
|
extern struct sock *dccp_v4_request_recv_sock(struct sock *sk,
|
|
|
|
|
struct sk_buff *skb,
|
|
|
|
|
struct request_sock *req,
|
|
|
|
|
struct dst_entry *dst);
|
|
|
|
|
extern struct sock *dccp_check_req(struct sock *sk, struct sk_buff *skb,
|
|
|
|
|
struct request_sock *req,
|
|
|
|
|
struct request_sock **prev);
|
|
|
|
|
|
|
|
|
|
extern int dccp_child_process(struct sock *parent, struct sock *child,
|
|
|
|
|
struct sk_buff *skb);
|
|
|
|
|
extern int dccp_rcv_state_process(struct sock *sk, struct sk_buff *skb,
|
|
|
|
|
struct dccp_hdr *dh, unsigned len);
|
|
|
|
|
extern int dccp_rcv_established(struct sock *sk, struct sk_buff *skb,
|
|
|
|
|
const struct dccp_hdr *dh, const unsigned len);
|
|
|
|
|
|
2006-03-20 22:00:37 -08:00
|
|
|
extern int dccp_init_sock(struct sock *sk, const __u8 ctl_sock_initialized);
|
2008-06-14 17:04:49 -07:00
|
|
|
extern void dccp_destroy_sock(struct sock *sk);
|
2005-12-13 23:24:16 -08:00
|
|
|
|
2005-08-09 20:14:34 -07:00
|
|
|
extern void dccp_close(struct sock *sk, long timeout);
|
|
|
|
|
extern struct sk_buff *dccp_make_response(struct sock *sk,
|
|
|
|
|
struct dst_entry *dst,
|
|
|
|
|
struct request_sock *req);
|
|
|
|
|
|
|
|
|
|
extern int dccp_connect(struct sock *sk);
|
|
|
|
|
extern int dccp_disconnect(struct sock *sk, int flags);
|
|
|
|
|
extern int dccp_getsockopt(struct sock *sk, int level, int optname,
|
2005-08-13 22:42:25 -03:00
|
|
|
char __user *optval, int __user *optlen);
|
|
|
|
|
extern int dccp_setsockopt(struct sock *sk, int level, int optname,
|
|
|
|
|
char __user *optval, int optlen);
|
2006-03-20 22:45:21 -08:00
|
|
|
#ifdef CONFIG_COMPAT
|
|
|
|
|
extern int compat_dccp_getsockopt(struct sock *sk,
|
|
|
|
|
int level, int optname,
|
|
|
|
|
char __user *optval, int __user *optlen);
|
|
|
|
|
extern int compat_dccp_setsockopt(struct sock *sk,
|
|
|
|
|
int level, int optname,
|
|
|
|
|
char __user *optval, int optlen);
|
|
|
|
|
#endif
|
2005-08-09 20:14:34 -07:00
|
|
|
extern int dccp_ioctl(struct sock *sk, int cmd, unsigned long arg);
|
2005-08-13 20:34:54 -03:00
|
|
|
extern int dccp_sendmsg(struct kiocb *iocb, struct sock *sk,
|
|
|
|
|
struct msghdr *msg, size_t size);
|
2005-08-09 20:14:34 -07:00
|
|
|
extern int dccp_recvmsg(struct kiocb *iocb, struct sock *sk,
|
|
|
|
|
struct msghdr *msg, size_t len, int nonblock,
|
|
|
|
|
int flags, int *addr_len);
|
|
|
|
|
extern void dccp_shutdown(struct sock *sk, int how);
|
2005-12-13 23:24:16 -08:00
|
|
|
extern int inet_dccp_listen(struct socket *sock, int backlog);
|
|
|
|
|
extern unsigned int dccp_poll(struct file *file, struct socket *sock,
|
|
|
|
|
poll_table *wait);
|
|
|
|
|
extern int dccp_v4_connect(struct sock *sk, struct sockaddr *uaddr,
|
|
|
|
|
int addr_len);
|
2005-08-09 20:14:34 -07:00
|
|
|
|
2008-04-03 14:20:52 -07:00
|
|
|
extern struct sk_buff *dccp_ctl_make_reset(struct sock *sk,
|
[DCCP]: Factor out common code for generating Resets
This factors code common to dccp_v{4,6}_ctl_send_reset into a separate function,
and adds support for filling in the Data 1 ... Data 3 fields from RFC 4340, 5.6.
It is useful to have this separate, since the following Reset codes will always
be generated from the control socket rather than via dccp_send_reset:
* Code 3, "No Connection", cf. 8.3.1;
* Code 4, "Packet Error" (identification for Data 1 added);
* Code 5, "Option Error" (identification for Data 1..3 added, will be used later);
* Code 6, "Mandatory Error" (same as Option Error);
* Code 7, "Connection Refused" (what on Earth is the difference to "No Connection"?);
* Code 8, "Bad Service Code";
* Code 9, "Too Busy";
* Code 10, "Bad Init Cookie" (not used).
Code 0 is not recommended by the RFC, the following codes would be used in
dccp_send_reset() instead, since they all relate to an established DCCP connection:
* Code 1, "Closed";
* Code 2, "Aborted";
* Code 11, "Aggression Penalty" (12.3).
Signed-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>
Signed-off-by: Arnaldo Carvalho de Melo <acme@ghostprotocols.net>
2007-09-26 14:35:19 -03:00
|
|
|
struct sk_buff *skb);
|
2006-03-20 19:25:24 -08:00
|
|
|
extern int dccp_send_reset(struct sock *sk, enum dccp_reset_codes code);
|
2005-08-23 21:50:06 -07:00
|
|
|
extern void dccp_send_close(struct sock *sk, const int active);
|
2005-12-13 23:24:16 -08:00
|
|
|
extern int dccp_invalid_packet(struct sk_buff *skb);
|
2008-09-04 07:30:19 +02:00
|
|
|
|
|
|
|
|
static inline u32 dccp_sane_rtt(long usec_sample)
|
|
|
|
|
{
|
|
|
|
|
if (unlikely(usec_sample <= 0 || usec_sample > DCCP_SANE_RTT_MAX))
|
|
|
|
|
DCCP_WARN("RTT sample %ld out of bounds!\n", usec_sample);
|
|
|
|
|
return clamp_val(usec_sample, DCCP_SANE_RTT_MIN, DCCP_SANE_RTT_MAX);
|
|
|
|
|
}
|
|
|
|
|
extern u32 dccp_sample_rtt(struct sock *sk, long delta);
|
2005-12-13 23:24:16 -08:00
|
|
|
|
|
|
|
|
static inline int dccp_bad_service_code(const struct sock *sk,
|
2006-03-20 19:23:32 -08:00
|
|
|
const __be32 service)
|
2005-12-13 23:24:16 -08:00
|
|
|
{
|
|
|
|
|
const struct dccp_sock *dp = dccp_sk(sk);
|
|
|
|
|
|
|
|
|
|
if (dp->dccps_service == service)
|
|
|
|
|
return 0;
|
|
|
|
|
return !dccp_list_has_service(dp->dccps_service_list, service);
|
|
|
|
|
}
|
2005-08-09 20:14:34 -07:00
|
|
|
|
2007-09-26 11:27:56 -03:00
|
|
|
/**
|
|
|
|
|
* dccp_skb_cb - DCCP per-packet control information
|
|
|
|
|
* @dccpd_type: one of %dccp_pkt_type (or unknown)
|
|
|
|
|
* @dccpd_ccval: CCVal field (5.1), see e.g. RFC 4342, 8.1
|
|
|
|
|
* @dccpd_reset_code: one of %dccp_reset_codes
|
|
|
|
|
* @dccpd_reset_data: Data1..3 fields (depend on @dccpd_reset_code)
|
|
|
|
|
* @dccpd_opt_len: total length of all options (5.8) in the packet
|
|
|
|
|
* @dccpd_seq: sequence number
|
|
|
|
|
* @dccpd_ack_seq: acknowledgment number subheader field value
|
|
|
|
|
* This is used for transmission as well as for reception.
|
|
|
|
|
*/
|
2005-08-09 20:14:34 -07:00
|
|
|
struct dccp_skb_cb {
|
2008-04-12 18:35:41 -07:00
|
|
|
union {
|
|
|
|
|
struct inet_skb_parm h4;
|
|
|
|
|
#if defined(CONFIG_IPV6) || defined (CONFIG_IPV6_MODULE)
|
|
|
|
|
struct inet6_skb_parm h6;
|
|
|
|
|
#endif
|
|
|
|
|
} header;
|
2005-09-16 16:58:40 -07:00
|
|
|
__u8 dccpd_type:4;
|
|
|
|
|
__u8 dccpd_ccval:4;
|
2007-09-26 11:27:56 -03:00
|
|
|
__u8 dccpd_reset_code,
|
|
|
|
|
dccpd_reset_data[3];
|
2005-09-16 16:58:40 -07:00
|
|
|
__u16 dccpd_opt_len;
|
2005-08-09 20:14:34 -07:00
|
|
|
__u64 dccpd_seq;
|
|
|
|
|
__u64 dccpd_ack_seq;
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
#define DCCP_SKB_CB(__skb) ((struct dccp_skb_cb *)&((__skb)->cb[0]))
|
|
|
|
|
|
2007-12-06 12:27:15 -02:00
|
|
|
/* RFC 4340, sec. 7.7 */
|
2005-08-09 20:14:34 -07:00
|
|
|
static inline int dccp_non_data_packet(const struct sk_buff *skb)
|
|
|
|
|
{
|
|
|
|
|
const __u8 type = DCCP_SKB_CB(skb)->dccpd_type;
|
|
|
|
|
|
|
|
|
|
return type == DCCP_PKT_ACK ||
|
|
|
|
|
type == DCCP_PKT_CLOSE ||
|
|
|
|
|
type == DCCP_PKT_CLOSEREQ ||
|
|
|
|
|
type == DCCP_PKT_RESET ||
|
|
|
|
|
type == DCCP_PKT_SYNC ||
|
|
|
|
|
type == DCCP_PKT_SYNCACK;
|
|
|
|
|
}
|
|
|
|
|
|
2007-12-06 12:27:15 -02:00
|
|
|
/* RFC 4340, sec. 7.7 */
|
|
|
|
|
static inline int dccp_data_packet(const struct sk_buff *skb)
|
|
|
|
|
{
|
|
|
|
|
const __u8 type = DCCP_SKB_CB(skb)->dccpd_type;
|
|
|
|
|
|
|
|
|
|
return type == DCCP_PKT_DATA ||
|
|
|
|
|
type == DCCP_PKT_DATAACK ||
|
|
|
|
|
type == DCCP_PKT_REQUEST ||
|
|
|
|
|
type == DCCP_PKT_RESPONSE;
|
|
|
|
|
}
|
|
|
|
|
|
2005-08-09 20:14:34 -07:00
|
|
|
static inline int dccp_packet_without_ack(const struct sk_buff *skb)
|
|
|
|
|
{
|
|
|
|
|
const __u8 type = DCCP_SKB_CB(skb)->dccpd_type;
|
|
|
|
|
|
|
|
|
|
return type == DCCP_PKT_DATA || type == DCCP_PKT_REQUEST;
|
|
|
|
|
}
|
|
|
|
|
|
2007-03-20 12:26:51 -03:00
|
|
|
#define DCCP_PKT_WITHOUT_ACK_SEQ (UINT48_MAX << 2)
|
2005-08-09 20:14:34 -07:00
|
|
|
|
|
|
|
|
static inline void dccp_hdr_set_seq(struct dccp_hdr *dh, const u64 gss)
|
|
|
|
|
{
|
2005-08-13 20:34:54 -03:00
|
|
|
struct dccp_hdr_ext *dhx = (struct dccp_hdr_ext *)((void *)dh +
|
|
|
|
|
sizeof(*dh));
|
2006-03-20 19:23:32 -08:00
|
|
|
dh->dccph_seq2 = 0;
|
|
|
|
|
dh->dccph_seq = htons((gss >> 32) & 0xfffff);
|
2005-08-09 20:14:34 -07:00
|
|
|
dhx->dccph_seq_low = htonl(gss & 0xffffffff);
|
|
|
|
|
}
|
|
|
|
|
|
2005-08-13 20:34:54 -03:00
|
|
|
static inline void dccp_hdr_set_ack(struct dccp_hdr_ack_bits *dhack,
|
|
|
|
|
const u64 gsr)
|
2005-08-09 20:14:34 -07:00
|
|
|
{
|
2006-03-20 19:23:32 -08:00
|
|
|
dhack->dccph_reserved1 = 0;
|
|
|
|
|
dhack->dccph_ack_nr_high = htons(gsr >> 32);
|
2005-08-09 20:14:34 -07:00
|
|
|
dhack->dccph_ack_nr_low = htonl(gsr & 0xffffffff);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static inline void dccp_update_gsr(struct sock *sk, u64 seq)
|
|
|
|
|
{
|
|
|
|
|
struct dccp_sock *dp = dccp_sk(sk);
|
|
|
|
|
|
2005-08-21 05:36:45 -03:00
|
|
|
dp->dccps_gsr = seq;
|
2008-09-04 07:30:19 +02:00
|
|
|
/* Sequence validity window depends on remote Sequence Window (7.5.1) */
|
|
|
|
|
dp->dccps_swl = SUB48(ADD48(dp->dccps_gsr, 1), dp->dccps_r_seq_win / 4);
|
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 07:30:19 +02:00
|
|
|
/*
|
|
|
|
|
* Adjust SWL so that it is not below ISR. In contrast to RFC 4340,
|
|
|
|
|
* 7.5.1 we perform this check beyond the initial handshake: W/W' are
|
|
|
|
|
* always > 32, so for the first W/W' packets in the lifetime of a
|
|
|
|
|
* connection we always have to adjust SWL.
|
|
|
|
|
* A second reason why we are doing this is that the window depends on
|
|
|
|
|
* the feature-remote value of Sequence Window: nothing stops the peer
|
|
|
|
|
* from updating this value while we are busy adjusting SWL for the
|
|
|
|
|
* first W packets (we would have to count from scratch again then).
|
|
|
|
|
* Therefore it is safer to always make sure that the Sequence Window
|
|
|
|
|
* is not artificially extended by a peer who grows SWL downwards by
|
|
|
|
|
* continually updating the feature-remote Sequence-Window.
|
|
|
|
|
* If sequence numbers wrap it is bad luck. But that will take a while
|
|
|
|
|
* (48 bit), and this measure prevents Sequence-number attacks.
|
|
|
|
|
*/
|
|
|
|
|
if (before48(dp->dccps_swl, dp->dccps_isr))
|
|
|
|
|
dp->dccps_swl = dp->dccps_isr;
|
2008-09-04 07:30:19 +02:00
|
|
|
dp->dccps_swh = ADD48(dp->dccps_gsr, (3 * dp->dccps_r_seq_win) / 4);
|
2005-08-09 20:14:34 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static inline void dccp_update_gss(struct sock *sk, u64 seq)
|
|
|
|
|
{
|
|
|
|
|
struct dccp_sock *dp = dccp_sk(sk);
|
|
|
|
|
|
2008-09-04 07:30:19 +02:00
|
|
|
dp->dccps_gss = seq;
|
|
|
|
|
/* Ack validity window depends on local Sequence Window value (7.5.1) */
|
|
|
|
|
dp->dccps_awl = SUB48(ADD48(dp->dccps_gss, 1), dp->dccps_l_seq_win);
|
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 07:30:19 +02:00
|
|
|
/* Adjust AWL so that it is not below ISS - see comment above for SWL */
|
|
|
|
|
if (before48(dp->dccps_awl, dp->dccps_iss))
|
|
|
|
|
dp->dccps_awl = dp->dccps_iss;
|
2008-09-04 07:30:19 +02:00
|
|
|
dp->dccps_awh = dp->dccps_gss;
|
2005-08-09 20:14:34 -07:00
|
|
|
}
|
2007-02-09 23:24:38 +09:00
|
|
|
|
dccp ccid-2: Implementation of circular Ack Vector buffer with overflow handling
This completes the implementation of a circular buffer for Ack Vectors, by
extending the current (linear array-based) implementation. The changes are:
(a) An `overflow' flag to deal with the case of overflow. As before, dynamic
growth of the buffer will not be supported; but code will be added to deal
robustly with overflowing Ack Vector buffers.
(b) A `tail_seqno' field. When naively implementing the algorithm of Appendix A
in RFC 4340, problems arise whenever subsequent Ack Vector records overlap,
which can bring the entire run length calculation completely out of synch.
(This is documented on http://www.erg.abdn.ac.uk/users/gerrit/dccp/notes/\
ack_vectors/tracking_tail_ackno/ .)
(c) The buffer lengthi is now computed dynamically (i.e. current fill level),
as the span between head to tail.
As a result, dccp_ackvec_pending() is now simpler - the #ifdef is no longer
necessary since buf_empty is always true when IP_DCCP_ACKVEC is not configured.
Note on overflow handling:
-------------------------
The Ack Vector code previously simply started to drop packets when the
Ack Vector buffer overflowed. This means that the userspace application
will not be able to receive, only because of an Ack Vector storage problem.
Furthermore, overflow may be transient, so that applications may later
recover from the overflow. Recovering from dropped packets is more difficult
(e.g. video key frames).
Hence the patch uses a different policy: when the buffer overflows, the oldest
entries are subsequently overwritten. This has a higher chance of recovery.
Details are on http://www.erg.abdn.ac.uk/users/gerrit/dccp/notes/ack_vectors/
Signed-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>
2008-09-04 07:30:19 +02:00
|
|
|
static inline int dccp_ackvec_pending(const struct sock *sk)
|
|
|
|
|
{
|
|
|
|
|
return dccp_sk(sk)->dccps_hc_rx_ackvec != NULL &&
|
|
|
|
|
!dccp_ackvec_is_empty(dccp_sk(sk)->dccps_hc_rx_ackvec);
|
|
|
|
|
}
|
|
|
|
|
|
2005-09-18 00:17:51 -07:00
|
|
|
static inline int dccp_ack_pending(const struct sock *sk)
|
|
|
|
|
{
|
dccp ccid-2: Implementation of circular Ack Vector buffer with overflow handling
This completes the implementation of a circular buffer for Ack Vectors, by
extending the current (linear array-based) implementation. The changes are:
(a) An `overflow' flag to deal with the case of overflow. As before, dynamic
growth of the buffer will not be supported; but code will be added to deal
robustly with overflowing Ack Vector buffers.
(b) A `tail_seqno' field. When naively implementing the algorithm of Appendix A
in RFC 4340, problems arise whenever subsequent Ack Vector records overlap,
which can bring the entire run length calculation completely out of synch.
(This is documented on http://www.erg.abdn.ac.uk/users/gerrit/dccp/notes/\
ack_vectors/tracking_tail_ackno/ .)
(c) The buffer lengthi is now computed dynamically (i.e. current fill level),
as the span between head to tail.
As a result, dccp_ackvec_pending() is now simpler - the #ifdef is no longer
necessary since buf_empty is always true when IP_DCCP_ACKVEC is not configured.
Note on overflow handling:
-------------------------
The Ack Vector code previously simply started to drop packets when the
Ack Vector buffer overflowed. This means that the userspace application
will not be able to receive, only because of an Ack Vector storage problem.
Furthermore, overflow may be transient, so that applications may later
recover from the overflow. Recovering from dropped packets is more difficult
(e.g. video key frames).
Hence the patch uses a different policy: when the buffer overflows, the oldest
entries are subsequently overwritten. This has a higher chance of recovery.
Details are on http://www.erg.abdn.ac.uk/users/gerrit/dccp/notes/ack_vectors/
Signed-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>
2008-09-04 07:30:19 +02:00
|
|
|
return dccp_ackvec_pending(sk) || inet_csk_ack_scheduled(sk);
|
2005-09-18 00:17:51 -07:00
|
|
|
}
|
2005-08-09 20:14:34 -07:00
|
|
|
|
dccp: Support for the exchange of NN options in established state
In contrast to static feature negotiation at the begin of a connection, which
establishes the capabilities of both endpoints, this patch introduces support
for dynamic exchange of feature negotiation options.
Such a dynamic exchange is necessary in at least two cases:
* CCID-2's Ack Ratio (RFC 4341, 6.1.2) which changes during the connection;
* Sequence Window values that, as per RFC 4340, 7.5.2, should be sent "as
as the connection progresses".
Both are NN (non-negotiable) features. Hence dynamic feature "negotiation" is
distinguished from static/pre-connection negotiation by the following:
* no new capabilities are negotiated (those that matter for the connection
are negotiated prior to setting up the connection, comparable to SIP);
* features must be understood by each endpoint: as per RFC 4340, 6.4,
Sequence Window is "Req'd" and Ack Ratio must be understood when CCID-2
is used as per the note underneath Table 4.
These characteristics are reflected in the implementation:
* only NN options can be exchanged after connection setup;
* NN options are activated directly after validating them. The rationale is
that a peer must accept every valid NN value (RFC 4340, 6.3.2), hence it
will either accept the value and send a "Confirm R", or it will send an
empty Confirm (which will reset the connection according to FN rules).
* An Ack is scheduled directly after activation to accelerate communicating
the update to the peer.
Signed-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>
Acked-by: Ian McDonald <ian.mcdonald@jandi.co.nz>
2008-09-04 07:30:19 +02:00
|
|
|
extern int dccp_feat_signal_nn_change(struct sock *sk, u8 feat, u64 nn_val);
|
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>
2008-09-04 07:30:19 +02:00
|
|
|
extern int dccp_feat_finalise_settings(struct dccp_sock *dp);
|
2008-09-04 07:30:19 +02:00
|
|
|
extern int dccp_feat_server_ccid_dependencies(struct dccp_request_sock *dreq);
|
2008-09-04 07:30:19 +02:00
|
|
|
extern int dccp_feat_insert_opts(struct dccp_sock*, struct dccp_request_sock*,
|
|
|
|
|
struct sk_buff *skb);
|
2008-09-04 07:30:19 +02:00
|
|
|
extern int dccp_feat_activate_values(struct sock *sk, struct list_head *fn);
|
2008-09-04 07:30:19 +02:00
|
|
|
extern void dccp_feat_list_purge(struct list_head *fn_list);
|
|
|
|
|
|
2006-03-20 22:32:06 -08:00
|
|
|
extern int dccp_insert_options(struct sock *sk, struct sk_buff *skb);
|
2007-12-13 12:38:11 -02:00
|
|
|
extern int dccp_insert_options_rsk(struct dccp_request_sock*, struct sk_buff*);
|
2006-03-20 22:32:06 -08:00
|
|
|
extern int dccp_insert_option_elapsed_time(struct sock *sk,
|
2005-08-09 20:14:34 -07:00
|
|
|
struct sk_buff *skb,
|
|
|
|
|
u32 elapsed_time);
|
2007-09-25 22:40:13 -07:00
|
|
|
extern u32 dccp_timestamp(void);
|
|
|
|
|
extern void dccp_timestamping_init(void);
|
2006-03-20 22:32:06 -08:00
|
|
|
extern int dccp_insert_option_timestamp(struct sock *sk,
|
2005-08-23 21:51:36 -07:00
|
|
|
struct sk_buff *skb);
|
2006-03-20 22:32:06 -08:00
|
|
|
extern int dccp_insert_option(struct sock *sk, struct sk_buff *skb,
|
2005-08-09 20:14:34 -07:00
|
|
|
unsigned char option,
|
|
|
|
|
const void *value, unsigned char len);
|
|
|
|
|
|
2006-03-20 19:25:02 -08:00
|
|
|
#ifdef CONFIG_SYSCTL
|
|
|
|
|
extern int dccp_sysctl_init(void);
|
|
|
|
|
extern void dccp_sysctl_exit(void);
|
|
|
|
|
#else
|
|
|
|
|
static inline int dccp_sysctl_init(void)
|
|
|
|
|
{
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static inline void dccp_sysctl_exit(void)
|
|
|
|
|
{
|
|
|
|
|
}
|
|
|
|
|
#endif
|
|
|
|
|
|
2005-08-09 20:14:34 -07:00
|
|
|
#endif /* _DCCP_H */
|