| 
									
										
										
										
											2005-08-12 09:27:49 -03: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 12:56:38 -03:00
										 |  |  | #include <linux/inet_diag.h>
 | 
					
						
							| 
									
										
										
										
											2005-08-12 09:27:49 -03: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-23 21:52:35 -07:00
										 |  |  | #include "ccid.h"
 | 
					
						
							| 
									
										
										
										
											2005-08-12 09:27:49 -03: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-23 21:52:35 -07: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-13 23: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-23 21:52:35 -07:00
										 |  |  | 
 | 
					
						
							| 
									
										
										
										
											2006-03-20 22:50:58 -08:00
										 |  |  | 	if (dccp_msk(sk)->dccpms_send_ack_vector) | 
					
						
							| 
									
										
											  
											
												[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-23 21:52:35 -07:00
										 |  |  | 		info->tcpi_options |= TCPI_OPT_SACK; | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | 	ccid_hc_rx_get_info(dp->dccps_hc_rx_ccid, sk, info); | 
					
						
							|  |  |  | 	ccid_hc_tx_get_info(dp->dccps_hc_tx_ccid, sk, info); | 
					
						
							|  |  |  | } | 
					
						
							|  |  |  | 
 | 
					
						
							| 
									
										
										
										
											2005-08-12 12:51:49 -03:00
										 |  |  | static void dccp_diag_get_info(struct sock *sk, struct inet_diag_msg *r, | 
					
						
							| 
									
										
										
										
											2005-08-12 09:27:49 -03:00
										 |  |  | 			       void *_info) | 
					
						
							|  |  |  | { | 
					
						
							| 
									
										
										
										
											2005-08-12 12:51:49 -03: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-23 21:52:35 -07:00
										 |  |  | 
 | 
					
						
							|  |  |  | 	if (_info != NULL) | 
					
						
							|  |  |  | 		dccp_get_info(sk, _info); | 
					
						
							| 
									
										
										
										
											2005-08-12 09:27:49 -03:00
										 |  |  | } | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | static struct inet_diag_handler dccp_diag_handler = { | 
					
						
							|  |  |  | 	.idiag_hashinfo	 = &dccp_hashinfo, | 
					
						
							|  |  |  | 	.idiag_get_info	 = dccp_diag_get_info, | 
					
						
							|  |  |  | 	.idiag_type	 = DCCPDIAG_GETSOCK, | 
					
						
							| 
									
										
											  
											
												[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-23 21:52:35 -07:00
										 |  |  | 	.idiag_info_size = sizeof(struct tcp_info), | 
					
						
							| 
									
										
										
										
											2005-08-12 09:27:49 -03: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"); | 
					
						
							| 
									
										
										
										
											2007-10-21 16:44:04 -07:00
										 |  |  | MODULE_ALIAS_NET_PF_PROTO_TYPE(PF_NETLINK, NETLINK_INET_DIAG, DCCPDIAG_GETSOCK); |