How to see amount of TCP retransmitting

Hi All,

I would like to see how many retransmissions are made for a given TCP
socket (due to ACKs not received in time). I don't understand the
output of /proc/net/tcp. It has a field called retrnsmt but I don't
know if that's what I want, one web site says that field is unused.

Is there no way to see how many packet has been retransmitted for a
given socket?

John <(E-Mail Removed)> wrote:
> I would like to see how many retransmissions are made for a given
> TCP socket (due to ACKs not received in time). I don't understand
> the output of /proc/net/tcp. It has a field called retrnsmt but I
> don't know if that's what I want, one web site says that field is
> unused.

> Is there no way to see how many packet has been retransmitted for a
> given socket?

Well, there is always the old fashioned way - tcpdump configured to
only trace those segments belonging to the TCP connection with which
the socket is associated.

If you are running in the context of the process, there is the
(non-portable) TCP_INFO) getsockopt() described in the tcp manpage.

rick jones
--
a wide gulf separates "what if" from "if only"
these opinions are mine, all mine; HP might not want them anyway...
feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...

> Well, there is always the old fashioned way - tcpdump configured to
> only trace those segments belonging to the TCP connection with which
> the socket is associated.

Specifying source and destination IP addresses and ports would do
that,
but how do I filter out only those packet that a retransmitted?

And will not entering promiscuous mode affect the situation quite a
lot?

> If you are running in the context of the process, there is the
> (non-portable) TCP_INFO) getsockopt() described in the tcp manpage.

This is unfortunately not the case.

John <(E-Mail Removed)> wrote:
> Specifying source and destination IP addresses and ports would do
> that, but how do I filter out only those packet that a
> retransmitted?

SMOPP - Small Matter Of Post Processing You would look at the TCP
segment sequence numbers and the lengths and see if any overlap.
Those are retransmissions.

> And will not entering promiscuous mode affect the situation quite a
> lot?

Promiscuous mode vs not in a "modern" switched network isn't that much
different since 99 times out of 10 your NIC doesn't see anything more
in promiscuous mode than it would have when not.

> > If you are running in the context of the process, there is the
> > (non-portable) TCP_INFO) getsockopt() described in the tcp manpage.

> This is unfortunately not the case.

If one cannot indeed access the FD's via other external means, you
could, in theory, create an LD_PRELOAD library which intercepts calls
to a suitable subset of the socket calls (perhaps just connect() and
accept() but I've not thought it through) and then dups the FDs, and
passes access rights to the dups to another process through a pipe.
That other process then could I presume make the desired getsockopt()
calls.

Of course, if one is already LD_PRELOADing and intercepting socket
calls, one could go further and intercept a few of the more commonly
called socket calls and have some logic which then occasionally
decided to make the setsockopt() calls actually in-process.

rick jones
--
Wisdom Teeth are impacted, people are affected by the effects of events.
these opinions are mine, all mine; HP might not want them anyway...
feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...