2005-08-12 20:27:49 +08:00
|
|
|
/*
|
|
|
|
|
* net/dccp/diag.c
|
|
|
|
|
*
|
|
|
|
|
* An implementation of the DCCP protocol
|
|
|
|
|
* Arnaldo Carvalho de Melo <acme@mandriva.com>
|
|
|
|
|
*
|
|
|
|
|
* 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/module.h>
|
2005-08-12 23:56:38 +08:00
|
|
|
#include <linux/inet_diag.h>
|
2005-08-12 20:27:49 +08:00
|
|
|
|
[DCCP]: Introduce dccp_get_info
And also hc_tx and hc_rx get_info functions for the CCIDs to fill in
information that is specific to them.
For now reusing struct tcp_info, later I'll try to figure out a better
solution, for now its really nice to get this kind of info:
[root@qemu ~]# ./ss -danemi
State Recv-Q Send-Q Local Addr:Port Peer Addr:Port
LISTEN 0 0 *:5001 *:* ino:628 sk:c1340040
mem:(r0,w0,f0,t0) cwnd:0 ssthresh:0
ESTAB 0 0 172.20.0.2:5001 172.20.0.1:32785 ino:629 sk:c13409a0
mem:(r0,w0,f0,t0) ts rto:1000 rtt:0.004/0 cwnd:0 ssthresh:0 rcv_rtt:61.377
This, for instance, shows that we're not congestion controlling ACKs,
as the above output is in the ttcp receiving host, and ttcp is a one
way app, i.e. the received never calls sendmsg, so
ccid_hc_tx_send_packet is never called, so the TX half connection
stays in TFRC_SSTATE_NO_SENT state and hctx_rtt is never calculated,
stays with the value set in ccid3_hc_tx_init, 4us, as show above in
milliseconds (0.004ms), upcoming patches will fix this.
rcv_rtt seems sane tho, matching ping results :-)
Signed-off-by: Arnaldo Carvalho de Melo <acme@mandriva.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2005-08-24 12:52:35 +08:00
|
|
|
#include "ccid.h"
|
2005-08-12 20:27:49 +08:00
|
|
|
#include "dccp.h"
|
|
|
|
|
|
[DCCP]: Introduce dccp_get_info
And also hc_tx and hc_rx get_info functions for the CCIDs to fill in
information that is specific to them.
For now reusing struct tcp_info, later I'll try to figure out a better
solution, for now its really nice to get this kind of info:
[root@qemu ~]# ./ss -danemi
State Recv-Q Send-Q Local Addr:Port Peer Addr:Port
LISTEN 0 0 *:5001 *:* ino:628 sk:c1340040
mem:(r0,w0,f0,t0) cwnd:0 ssthresh:0
ESTAB 0 0 172.20.0.2:5001 172.20.0.1:32785 ino:629 sk:c13409a0
mem:(r0,w0,f0,t0) ts rto:1000 rtt:0.004/0 cwnd:0 ssthresh:0 rcv_rtt:61.377
This, for instance, shows that we're not congestion controlling ACKs,
as the above output is in the ttcp receiving host, and ttcp is a one
way app, i.e. the received never calls sendmsg, so
ccid_hc_tx_send_packet is never called, so the TX half connection
stays in TFRC_SSTATE_NO_SENT state and hctx_rtt is never calculated,
stays with the value set in ccid3_hc_tx_init, 4us, as show above in
milliseconds (0.004ms), upcoming patches will fix this.
rcv_rtt seems sane tho, matching ping results :-)
Signed-off-by: Arnaldo Carvalho de Melo <acme@mandriva.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2005-08-24 12:52:35 +08:00
|
|
|
static void dccp_get_info(struct sock *sk, struct tcp_info *info)
|
|
|
|
|
{
|
|
|
|
|
struct dccp_sock *dp = dccp_sk(sk);
|
|
|
|
|
const struct inet_connection_sock *icsk = inet_csk(sk);
|
|
|
|
|
|
|
|
|
|
memset(info, 0, sizeof(*info));
|
|
|
|
|
|
|
|
|
|
info->tcpi_state = sk->sk_state;
|
|
|
|
|
info->tcpi_retransmits = icsk->icsk_retransmits;
|
|
|
|
|
info->tcpi_probes = icsk->icsk_probes_out;
|
|
|
|
|
info->tcpi_backoff = icsk->icsk_backoff;
|
2005-12-14 15:26:10 +08:00
|
|
|
info->tcpi_pmtu = icsk->icsk_pmtu_cookie;
|
[DCCP]: Introduce dccp_get_info
And also hc_tx and hc_rx get_info functions for the CCIDs to fill in
information that is specific to them.
For now reusing struct tcp_info, later I'll try to figure out a better
solution, for now its really nice to get this kind of info:
[root@qemu ~]# ./ss -danemi
State Recv-Q Send-Q Local Addr:Port Peer Addr:Port
LISTEN 0 0 *:5001 *:* ino:628 sk:c1340040
mem:(r0,w0,f0,t0) cwnd:0 ssthresh:0
ESTAB 0 0 172.20.0.2:5001 172.20.0.1:32785 ino:629 sk:c13409a0
mem:(r0,w0,f0,t0) ts rto:1000 rtt:0.004/0 cwnd:0 ssthresh:0 rcv_rtt:61.377
This, for instance, shows that we're not congestion controlling ACKs,
as the above output is in the ttcp receiving host, and ttcp is a one
way app, i.e. the received never calls sendmsg, so
ccid_hc_tx_send_packet is never called, so the TX half connection
stays in TFRC_SSTATE_NO_SENT state and hctx_rtt is never calculated,
stays with the value set in ccid3_hc_tx_init, 4us, as show above in
milliseconds (0.004ms), upcoming patches will fix this.
rcv_rtt seems sane tho, matching ping results :-)
Signed-off-by: Arnaldo Carvalho de Melo <acme@mandriva.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2005-08-24 12:52:35 +08:00
|
|
|
|
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, as it now is handled fully dynamically via feature negotiation
(i.e. when CCID-2 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.
There was a FIXME to change the error code when dccp_ackvec_add() fails.
I removed this after finding out 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.
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>
2008-12-08 17:19:06 +08:00
|
|
|
if (dp->dccps_hc_rx_ackvec != NULL)
|
[DCCP]: Introduce dccp_get_info
And also hc_tx and hc_rx get_info functions for the CCIDs to fill in
information that is specific to them.
For now reusing struct tcp_info, later I'll try to figure out a better
solution, for now its really nice to get this kind of info:
[root@qemu ~]# ./ss -danemi
State Recv-Q Send-Q Local Addr:Port Peer Addr:Port
LISTEN 0 0 *:5001 *:* ino:628 sk:c1340040
mem:(r0,w0,f0,t0) cwnd:0 ssthresh:0
ESTAB 0 0 172.20.0.2:5001 172.20.0.1:32785 ino:629 sk:c13409a0
mem:(r0,w0,f0,t0) ts rto:1000 rtt:0.004/0 cwnd:0 ssthresh:0 rcv_rtt:61.377
This, for instance, shows that we're not congestion controlling ACKs,
as the above output is in the ttcp receiving host, and ttcp is a one
way app, i.e. the received never calls sendmsg, so
ccid_hc_tx_send_packet is never called, so the TX half connection
stays in TFRC_SSTATE_NO_SENT state and hctx_rtt is never calculated,
stays with the value set in ccid3_hc_tx_init, 4us, as show above in
milliseconds (0.004ms), upcoming patches will fix this.
rcv_rtt seems sane tho, matching ping results :-)
Signed-off-by: Arnaldo Carvalho de Melo <acme@mandriva.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2005-08-24 12:52:35 +08:00
|
|
|
info->tcpi_options |= TCPI_OPT_SACK;
|
|
|
|
|
|
2008-12-18 08:08:01 +08:00
|
|
|
if (dp->dccps_hc_rx_ccid != NULL)
|
|
|
|
|
ccid_hc_rx_get_info(dp->dccps_hc_rx_ccid, sk, info);
|
|
|
|
|
|
|
|
|
|
if (dp->dccps_hc_tx_ccid != NULL)
|
|
|
|
|
ccid_hc_tx_get_info(dp->dccps_hc_tx_ccid, sk, info);
|
[DCCP]: Introduce dccp_get_info
And also hc_tx and hc_rx get_info functions for the CCIDs to fill in
information that is specific to them.
For now reusing struct tcp_info, later I'll try to figure out a better
solution, for now its really nice to get this kind of info:
[root@qemu ~]# ./ss -danemi
State Recv-Q Send-Q Local Addr:Port Peer Addr:Port
LISTEN 0 0 *:5001 *:* ino:628 sk:c1340040
mem:(r0,w0,f0,t0) cwnd:0 ssthresh:0
ESTAB 0 0 172.20.0.2:5001 172.20.0.1:32785 ino:629 sk:c13409a0
mem:(r0,w0,f0,t0) ts rto:1000 rtt:0.004/0 cwnd:0 ssthresh:0 rcv_rtt:61.377
This, for instance, shows that we're not congestion controlling ACKs,
as the above output is in the ttcp receiving host, and ttcp is a one
way app, i.e. the received never calls sendmsg, so
ccid_hc_tx_send_packet is never called, so the TX half connection
stays in TFRC_SSTATE_NO_SENT state and hctx_rtt is never calculated,
stays with the value set in ccid3_hc_tx_init, 4us, as show above in
milliseconds (0.004ms), upcoming patches will fix this.
rcv_rtt seems sane tho, matching ping results :-)
Signed-off-by: Arnaldo Carvalho de Melo <acme@mandriva.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2005-08-24 12:52:35 +08:00
|
|
|
}
|
|
|
|
|
|
2005-08-12 23:51:49 +08:00
|
|
|
static void dccp_diag_get_info(struct sock *sk, struct inet_diag_msg *r,
|
2005-08-12 20:27:49 +08:00
|
|
|
void *_info)
|
|
|
|
|
{
|
2005-08-12 23:51:49 +08:00
|
|
|
r->idiag_rqueue = r->idiag_wqueue = 0;
|
[DCCP]: Introduce dccp_get_info
And also hc_tx and hc_rx get_info functions for the CCIDs to fill in
information that is specific to them.
For now reusing struct tcp_info, later I'll try to figure out a better
solution, for now its really nice to get this kind of info:
[root@qemu ~]# ./ss -danemi
State Recv-Q Send-Q Local Addr:Port Peer Addr:Port
LISTEN 0 0 *:5001 *:* ino:628 sk:c1340040
mem:(r0,w0,f0,t0) cwnd:0 ssthresh:0
ESTAB 0 0 172.20.0.2:5001 172.20.0.1:32785 ino:629 sk:c13409a0
mem:(r0,w0,f0,t0) ts rto:1000 rtt:0.004/0 cwnd:0 ssthresh:0 rcv_rtt:61.377
This, for instance, shows that we're not congestion controlling ACKs,
as the above output is in the ttcp receiving host, and ttcp is a one
way app, i.e. the received never calls sendmsg, so
ccid_hc_tx_send_packet is never called, so the TX half connection
stays in TFRC_SSTATE_NO_SENT state and hctx_rtt is never calculated,
stays with the value set in ccid3_hc_tx_init, 4us, as show above in
milliseconds (0.004ms), upcoming patches will fix this.
rcv_rtt seems sane tho, matching ping results :-)
Signed-off-by: Arnaldo Carvalho de Melo <acme@mandriva.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2005-08-24 12:52:35 +08:00
|
|
|
|
|
|
|
|
if (_info != NULL)
|
|
|
|
|
dccp_get_info(sk, _info);
|
2005-08-12 20:27:49 +08:00
|
|
|
}
|
|
|
|
|
|
2011-12-09 14:23:18 +08:00
|
|
|
static void dccp_diag_dump(struct sk_buff *skb, struct netlink_callback *cb,
|
2015-03-10 22:15:54 +08:00
|
|
|
const struct inet_diag_req_v2 *r, struct nlattr *bc)
|
2011-12-09 14:23:18 +08:00
|
|
|
{
|
|
|
|
|
inet_diag_dump_icsk(&dccp_hashinfo, skb, cb, r, bc);
|
|
|
|
|
}
|
|
|
|
|
|
2015-03-10 22:15:54 +08:00
|
|
|
static int dccp_diag_dump_one(struct sk_buff *in_skb,
|
|
|
|
|
const struct nlmsghdr *nlh,
|
|
|
|
|
const struct inet_diag_req_v2 *req)
|
2011-12-09 14:23:18 +08:00
|
|
|
{
|
|
|
|
|
return inet_diag_dump_one_icsk(&dccp_hashinfo, in_skb, nlh, req);
|
|
|
|
|
}
|
|
|
|
|
|
2008-11-20 07:43:27 +08:00
|
|
|
static const struct inet_diag_handler dccp_diag_handler = {
|
2011-12-09 14:23:18 +08:00
|
|
|
.dump = dccp_diag_dump,
|
|
|
|
|
.dump_one = dccp_diag_dump_one,
|
2005-08-12 20:27:49 +08:00
|
|
|
.idiag_get_info = dccp_diag_get_info,
|
2011-12-06 16:05:24 +08:00
|
|
|
.idiag_type = IPPROTO_DCCP,
|
2015-06-15 23:26:19 +08:00
|
|
|
.idiag_info_size = sizeof(struct tcp_info),
|
2005-08-12 20:27:49 +08:00
|
|
|
};
|
|
|
|
|
|
|
|
|
|
static int __init dccp_diag_init(void)
|
|
|
|
|
{
|
|
|
|
|
return inet_diag_register(&dccp_diag_handler);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void __exit dccp_diag_fini(void)
|
|
|
|
|
{
|
|
|
|
|
inet_diag_unregister(&dccp_diag_handler);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
module_init(dccp_diag_init);
|
|
|
|
|
module_exit(dccp_diag_fini);
|
|
|
|
|
|
|
|
|
|
MODULE_LICENSE("GPL");
|
|
|
|
|
MODULE_AUTHOR("Arnaldo Carvalho de Melo <acme@mandriva.com>");
|
|
|
|
|
MODULE_DESCRIPTION("DCCP inet_diag handler");
|
2011-12-15 10:43:27 +08:00
|
|
|
MODULE_ALIAS_NET_PF_PROTO_TYPE(PF_NETLINK, NETLINK_SOCK_DIAG, 2-33 /* AF_INET - IPPROTO_DCCP */);
|