2007-05-24 05:46:35 +08:00
|
|
|
menuconfig IP_DCCP
|
2005-08-10 11:14:34 +08:00
|
|
|
tristate "The DCCP Protocol (EXPERIMENTAL)"
|
2007-05-24 05:46:35 +08:00
|
|
|
depends on INET && EXPERIMENTAL
|
2005-08-10 11:14:34 +08:00
|
|
|
---help---
|
2006-10-25 07:17:51 +08:00
|
|
|
Datagram Congestion Control Protocol (RFC 4340)
|
2005-08-10 11:14:34 +08:00
|
|
|
|
2006-10-25 07:17:51 +08:00
|
|
|
From http://www.ietf.org/rfc/rfc4340.txt:
|
2005-08-10 11:14:34 +08:00
|
|
|
|
|
|
|
The Datagram Congestion Control Protocol (DCCP) is a transport
|
|
|
|
protocol that implements bidirectional, unicast connections of
|
|
|
|
congestion-controlled, unreliable datagrams. It should be suitable
|
|
|
|
for use by applications such as streaming media, Internet telephony,
|
2006-10-25 07:17:51 +08:00
|
|
|
and on-line games.
|
2005-08-10 11:14:34 +08:00
|
|
|
|
|
|
|
To compile this protocol support as a module, choose M here: the
|
|
|
|
module will be called dccp.
|
|
|
|
|
|
|
|
If in doubt, say N.
|
|
|
|
|
2007-05-24 05:46:35 +08:00
|
|
|
if IP_DCCP
|
|
|
|
|
[INET_DIAG]: Move the tcp_diag interface to the proper place
With this the previous setup is back, i.e. tcp_diag can be built as a module,
as dccp_diag and both share the infrastructure available in inet_diag.
If one selects CONFIG_INET_DIAG as module CONFIG_INET_TCP_DIAG will also be
built as a module, as will CONFIG_INET_DCCP_DIAG, if CONFIG_IP_DCCP was
selected static or as a module, if CONFIG_INET_DIAG is y, being statically
linked CONFIG_INET_TCP_DIAG will follow suit and CONFIG_INET_DCCP_DIAG will be
built in the same manner as CONFIG_IP_DCCP.
Now to aim at UDP, converting it to use inet_hashinfo, so that we can use
iproute2 for UDP sockets as well.
Ah, just to show an example of this new infrastructure working for DCCP :-)
[root@qemu ~]# ./ss -dane
State Recv-Q Send-Q Local Address:Port Peer Address:Port
LISTEN 0 0 *:5001 *:* ino:942 sk:cfd503a0
ESTAB 0 0 127.0.0.1:5001 127.0.0.1:32770 ino:943 sk:cfd50a60
ESTAB 0 0 127.0.0.1:32770 127.0.0.1:5001 ino:947 sk:cfd50700
TIME-WAIT 0 0 127.0.0.1:32769 127.0.0.1:5001 timer:(timewait,3.430ms,0) ino:0 sk:cf209620
Signed-off-by: Arnaldo Carvalho de Melo <acme@mandriva.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2005-08-12 23:59:17 +08:00
|
|
|
config INET_DCCP_DIAG
|
2007-05-24 05:46:35 +08:00
|
|
|
depends on INET_DIAG
|
[INET_DIAG]: Move the tcp_diag interface to the proper place
With this the previous setup is back, i.e. tcp_diag can be built as a module,
as dccp_diag and both share the infrastructure available in inet_diag.
If one selects CONFIG_INET_DIAG as module CONFIG_INET_TCP_DIAG will also be
built as a module, as will CONFIG_INET_DCCP_DIAG, if CONFIG_IP_DCCP was
selected static or as a module, if CONFIG_INET_DIAG is y, being statically
linked CONFIG_INET_TCP_DIAG will follow suit and CONFIG_INET_DCCP_DIAG will be
built in the same manner as CONFIG_IP_DCCP.
Now to aim at UDP, converting it to use inet_hashinfo, so that we can use
iproute2 for UDP sockets as well.
Ah, just to show an example of this new infrastructure working for DCCP :-)
[root@qemu ~]# ./ss -dane
State Recv-Q Send-Q Local Address:Port Peer Address:Port
LISTEN 0 0 *:5001 *:* ino:942 sk:cfd503a0
ESTAB 0 0 127.0.0.1:5001 127.0.0.1:32770 ino:943 sk:cfd50a60
ESTAB 0 0 127.0.0.1:32770 127.0.0.1:5001 ino:947 sk:cfd50700
TIME-WAIT 0 0 127.0.0.1:32769 127.0.0.1:5001 timer:(timewait,3.430ms,0) ino:0 sk:cf209620
Signed-off-by: Arnaldo Carvalho de Melo <acme@mandriva.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2005-08-12 23:59:17 +08:00
|
|
|
def_tristate y if (IP_DCCP = y && INET_DIAG = y)
|
2005-08-12 20:27:49 +08:00
|
|
|
def_tristate m
|
|
|
|
|
2005-08-10 11:14:34 +08:00
|
|
|
source "net/dccp/ccids/Kconfig"
|
|
|
|
|
2005-08-14 07:35:39 +08:00
|
|
|
menu "DCCP Kernel Hacking"
|
2007-05-24 05:46:35 +08:00
|
|
|
depends on DEBUG_KERNEL=y
|
2005-08-14 07:35:39 +08:00
|
|
|
|
|
|
|
config IP_DCCP_DEBUG
|
|
|
|
bool "DCCP debug messages"
|
|
|
|
---help---
|
|
|
|
Only use this if you're hacking DCCP.
|
|
|
|
|
2006-11-21 04:26:03 +08:00
|
|
|
When compiling DCCP as a module, this debugging output can be toggled
|
|
|
|
by setting the parameter dccp_debug of the `dccp' module to 0 or 1.
|
|
|
|
|
2005-08-14 07:35:39 +08:00
|
|
|
Just say N.
|
|
|
|
|
2006-09-22 10:28:01 +08:00
|
|
|
config NET_DCCPPROBE
|
|
|
|
tristate "DCCP connection probing"
|
|
|
|
depends on PROC_FS && KPROBES
|
|
|
|
---help---
|
|
|
|
This module allows for capturing the changes to DCCP connection
|
|
|
|
state in response to incoming packets. It is used for debugging
|
|
|
|
DCCP congestion avoidance modules. If you don't understand
|
|
|
|
what was just said, you don't need it: say N.
|
|
|
|
|
2006-11-10 23:04:52 +08:00
|
|
|
Documentation on how to use DCCP connection probing can be found
|
2010-11-16 03:55:34 +08:00
|
|
|
at:
|
|
|
|
|
|
|
|
http://www.linuxfoundation.org/collaborate/workgroups/networking/dccpprobe
|
2006-09-22 10:28:01 +08:00
|
|
|
|
|
|
|
To compile this code as a module, choose M here: the
|
|
|
|
module will be called dccp_probe.
|
|
|
|
|
|
|
|
|
2005-08-14 07:35:39 +08:00
|
|
|
endmenu
|
|
|
|
|
2007-05-24 05:46:35 +08:00
|
|
|
endif # IP_DDCP
|