brescia@CCV.BBN.COM.UUCP (02/25/87)
For each type of host implementation of IP/TCP/TELNET, where may the tcp error
counters be found? I realize that some UNIX(tm) systems and derivatives
provide a netstat command with a '-s' option that gives the following counters
for the tcp level.
tcp:
0 bad header checksums
0 bad header offset fields
0 incomplete headers
The information I am looking for is a measure (either per-connection or over
the whole operation of the tcp protocol layer)
retransmissions - count of segments resent because ack was not returned in time
redundant receives - count of segments received more than once
estimated round trip time (per connection) - delay to destination
retransmission time (or algorithm from est. RT time)
route (on UNIX() can get this from netstat -r) - gateway or interface used
when a connection is closed, the reason for closing
For your implementation, are these sort of numbers available to me, a lowly
user, and if not, can a wizard get them using some debugging magic?
Implementations ::= { tops20, 4.*bsd, bbnos, ultrix 1.*, 2.*, vms(wolongong),
many others? }
I have taken a call from a user who is unable to reliably get from host A to
host B, in that the connections hang for long periods of time, and frequently
break (connection closed). While there are 3 different kinds of gateway in
this particular path, I think the routing and traffic load are stable enough
to support useful ftp and telnet service. I want to be able to have her call
her host wizard to find out what is failing at the end points.
mikevan@LBL-CSAM.ARPA.UUCP (03/02/87)
>>I realize that some UNIX(tm) systems and derivatives provide a >>netstat command with a '-s' option that gives the following >>counters for the tcp level. >> >>tcp: >> 0 bad header checksums >> 0 bad header offset fields >> 0 incomplete headers Mike Karels and I recently expanded the tcp counters in 4bsd. "netstat -s" now spits out the following tcp info: tcp: 409459 packets sent 348357 data packets (176132584 bytes) 4580 data packets (4180410 bytes) retransmitted 36809 ack-only packets (35384 delayed) 37 URG only packets 470 window probe packets 17169 window update packets 2037 control packets 388768 packets received 215725 acks (for 176151367 bytes) 31643 duplicate acks 0 acks for unsent data 204363 packets (40447108 bytes) received in-sequence 5905 completely duplicate packets (21670 bytes) 104 packets with some dup. data (195 bytes duped) 795 out-of-order packets (15985 bytes) 1 packet (1024 bytes) of data after window 7 window probes 3219 window update packets 0 packets received after close 0 discarded for bad checksums 0 discarded for bad header offset fields 0 discarded because packet too short 729 connection requests 425 connection accepts 1069 connections established (including accepts) 1183 connections closed (including 9 drops) 93 embryonic connections dropped 178425 segments updated rtt (of 179970 attempts) 3745 retransmit timeouts 1 connection dropped by rexmit timeout 315 persist timeouts 77992 keepalive timeouts 21298 keepalive probes sent 73 connections dropped by keepalive This includes almost everything you were asking about though some of the numbers require a good understanding of the 4bsd tcp implementation to interpret. I promised Mike that I would write a short document (probably an appendix to the 4bsd "Networking Implementation Notes") saying what these numbers mean and how various ratios and differences can be used to find network problems. I have about 30 pages of notes on good things to include in this document but it will probably take me two or three months to get round to writing it. This stuff will presumably go out with the next BSD release. It might even become available as a "bug fix" or something before the next release (I speak from complete ignorance -- I know nothing about BSD distribution policies or plans). I do know that Wollongong has a VMS version of the 4.3bsd networking code that includes these stats (though they don't seem to be distributing it yet -- bang on your TWG salesman if you want it). I also have a strong suspicion that SRI's Multinet will soon include these stats. - Van ps: given the problem you're working on, the socket debugging option and "trpt" might be a quicker way to find it. E.g., "ftp -d host-B" to generate some traffic with debugging enabled then "/etc/trpt -f" (with, say, an ftp data transfer running) to get a complete protocol trace including all the packet arrivals and departures, state transitions, timeouts, rtt's and srtt estimates, user process actions, etc. ("man 8 trpt" will get you more information on how to use it and what optional information is available). Trpt, like netstat, should be available to any "lowly user" on a 4bsd system.