All rights reserved.
Redistribution and use in source and binary forms are permitted
provided that the above copyright notice and this paragraph are
duplicated in all such forms and that any documentation,
advertising materials, and other materials related to such
distribution and use acknowledge that the software was developed
by the University of California, Berkeley. The name of the
University may not be used to endorse or promote products derived
from this software without specific prior written permission.
THIS SOFTWARE IS PROVIDED ``AS IS'' AND WITHOUT ANY EXPRESS OR
IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED
WARRANTIES OF MERCHANTIBILITY AND FITNESS FOR A PARTICULAR PURPOSE.
@(#)trsp.8 6.2 (Berkeley) 09/20/88
-s in addition to the normal output, print a detailed description of the packet sequencing information,
-t in addition to the normal output, print the values for all timers at each point in the trace,
-j just give a list of the protocol control block addresses for which there are trace records,
-p show only trace records associated with the protocol control block who's address follows,
-a in addition to the normal output, print the values of the source and destination addresses for each packet recorded.
The recommended use of trsp is as follows. Isolate the problem and enable debugging on the socket(s) involved in the connection. Find the address of the protocol control blocks associated with the sockets using the -A option to netstat (1). Then run trsp with the -p option, supplying the associated protocol control block addresses. If there are many sockets using the debugging option, the -j option may be useful in checking to see if any trace records are present for the socket in question.
If debugging is being performed on a system or core file other than the default, the last two arguments may be used to supplant the defaults.
The output format is inscrutable and should be described here.