This program is the first step in an LTP connection graphing program. Right now it takes an LTP packet capture (LTP in UDP or DCCP in IP in Ethernet) and converts it to a TCP packet capture. When this TCP capture is examined using Tcptrace (http://www.tcptrace.org), you see a graphical description of the LTP connection. In order to build this program, please simply type make at the commandline. I have not included a ./configure script at this time. Contact me, if major problems arise. Usage is as follows: ltptrace -t{encapsulation} ltp_file tcp_file [-d] [-b{block_size}] [-s{start session}-{end session}] -d is debug (repeat for additional verbosity) -t specifies what protocol LTP is encapsulated in. Right now, only udp and dccp are supported. -b specifies the LTP block size (NOT the bundle size) that is being used over this connection. This information can't be determined from a packet capture, so if not specified it defaults to is 500,000. If you set this value larger than your actual block size, the graph will contain empty spaces between each session, which is handy to separate sessions. However, in that case, tcptrace will report inaccurate, lost data statistics. -s requests a graph of only the specified range of sessions. Note that the session numbers are just the "session number" from wireshark, not the whole session id. To generate the graphs run: ltptrace -tudp ltp_file.dmp tcp_file.dmp tcptrace -lGt tcp_file.dmp xplot a2b_tsg.xpl Plot Interpretation: 1. The only Tcptrace graphs that are valid are the Throughput Graph(tput) and Time Sequence Graph (tsg). The TSG is the main graph you want to look at. 2. White segments with arrows at both ends are LTP data segments (for those familiar with tcptrace, these are represented by TCP data carrying packets). 3. Purple vertical lines are LTP report segments. The lines show the parts of the session that the receiver is acknowledging (represented by TCP SACKS). 4. White crosses are LTP report acknowledgment segments (represented by TCP zero length data segments). 5. Retransmitted data is marked in red, just as in TCP. 6. LTP cancel and cancel ack segments have a RST_IN or RST_OUT over them (they become TCP Reset packets). 7. The green line is the point below which all data has been acknowledged, just as in TCP. 8. The yellow line has no meaning for LTP. 9. Note that there may be sequence number space between two adjacent sessions. This doesn't necessarily indicate loss. Since the block size is not contained in the packet capture, we have to guess what it should be. If that guess is wrong, there will be additional "space" in each session that isn't filled. Use the -b option to specify the correct block size to eliminate this space. 10. A SYN/SYNACK/ACK and FIN/FINACK/ACK are added to the begining and end of the connection. These are purely to make the TCP connections pretty and do not correspond to any packets in the LTP capture. Statistics: Most of the Tcptrace statistics are valid. However, those relating to the receiver's window are meaningless because the window represents nothing in the LTP capture. Unless the block size was specified, the "missed data" statistic is also wrong. The rest of the statistics, including those about the number of packets, number of retransmissions, idle time, and throughput are valid. Limitations: 1)Only handles one LTP "connection". There isn't a good way to separate different LTP "connections" from new sessions of the same "connection". Use Tcpdump filters to separate connections. Libpcap filtering could also be added in ltptrace. 2)Uses some special types from Linux (u_char, u_int32_t) ltptrace is free software: you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version. ltptrace is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. You should have received a copy of the GNU General Public License along with ltptrace. If not, see . Samuel Jero Internetworking Research Group Ohio University sj323707@ohio.edu 2/23/2011