1Mon Jun 24 16:42:44 PDT 1991 2Version 2.1beta 3 4This directory contains a beta release of tcpdump version 2.1 and the 5Berkeley Packet Filter, BPF. Tcpdump now runs on following platforms: 6 7 machine os pcap 8 ------- -- ---- 9 hp300 4.3BSD Tahoe, 4.3BSD Reno bpf 10 sparc SunOS 4.x bpf, nit 11 sun3 SunOS 3.5, SunOS 4.x bpf, nit 12 Decstation Ultrix 4.0 (and higher) packetfilter 13 IBM RT 4.3BSD enet 14 15BPF can be installed SunOS kernels, provided you have source, 4.3BSD 16kernels, and is now standard in BSD systems. (The "Februrary Tape" 17from CSRG has BPF support. Tcpdump can be temporarily found in 18/usr/src/contrib.) See bpf/README for further details and an 19installation procedure. 20 21This release contains mostly bug fixes from 2.0. Additionally, the 22bpf model underwent some changes and the filter code optimizer has 23been improved. Most changes will be transparent to the user. 24One exception is that 'icmp' is now a keyword, so you can say 25 26 % tcpdump 'icmp[0] != 8 and icmp[0] != 0' 27 28to get non-echo/reply ICMP packets. 29 30The BPF kernel interface has changed a bit (with respect to ioctls) so 31if you are using BPF, the new tcpdump won't work with old kernels. 32Also, if you've written any BPF applications, they may need some minor 33changes. The BPF man page has gotten a little better and now contains 34an explanation of the filtering language. 35 36Problems, bugs, questions, desirable enhancements, etc., should be 37sent to the email address "tcpdump@ee.lbl.gov". We are very 38interested in hearing about any problems you may encounter, especially 39those relating to the BPF kernel modifications. Undoubtedly, some 40aspects of the installation may be unclear, and your feedback will 41be valued as a means of making this package as easy to use as possible. 42Also, tcpdump's makefile has continued to evolve. Multiple platforms 43are supported using subdirectories. See INSTALL for more details. 44 45 - Steve McCanne (mccanne@ee.lbl.gov) 46 Craig Leres (leres@ee.lbl.gov) 47 Van Jacobson (van@ee.lbl.gov) 48 49------------------------------ 50 51Old news: 52 53 - A packet dumper has been added (thanks to Jeff Mogul of DECWRL). 54 With this option, you can create an architecture independent binary 55 trace file in real time, without the overhead of the packet printer. 56 At a later time, the packets can be filtered (again) and printed. 57 58 - BSD is supported. You must install BPF in your kernel. 59 Since the filtering is now done in the kernel, fewer packets are 60 dropped. In fact, with BPF and the packet dumper option, a measly 61 Sun 3/50 can keep up with a busy network. 62 63 - Compressed SLIP packets can now be dumped, provided you use our 64 SLIP software and BPF. These packets are dumped as any other IP 65 packet; the compressed headers are dumped with the '-e' option. 66 67 - Machines with little-endian byte ordering are supported (thanks to 68 Jeff Mogul). 69 70 - Ultrix 4.0 is supported (also thanks to Jeff Mogul). 71 72 - IBM RT and Stanford Enetfilter support has been added by 73 Rayan Zachariassen <rayan@canet.ca>. Tcpdump has been tested under 74 both the vanilla enetfilter interface, and the extended interface 75 (#ifdef'd by IBMRTPC) present in the MERIT version of the enetfilter. 76 77 - TFTP packets are now printed (requests only). 78 79 - BOOTP packets are now printed. 80 81 - SNMP packets are now printed. (thanks to John LoVerso of Xylogics). 82 83 - Sparc architectures, including the Sparcstation-1, are now 84 supported thanks to Steve McCanne and Craig Leres. 85 86 - SunOS 4 is now supported thanks to Micky Liu of Columbia 87 University (micky@cunixc.cc.columbia.edu). 88 89 - IP options are now printed. 90 91 - RIP packets are now printed. 92 93 - There's a -v flag that prints out more information than the 94 default (e.g., it will enable printing of IP ttl, tos and id) 95 and -q flag that prints out less (e.g., it will disable 96 interpretation of AppleTalk-in-UDP). 97 98 - The grammar has undergone substantial changes (if you have an 99 earlier version of tcpdump, you should re-read the manual 100 entry). 101 102 The most useful change is the addition of an expression 103 syntax that lets you filter on arbitrary fields or values in the 104 packet. E.g., "ip[0] > 0x45" would print only packets with IP 105 options, "tcp[13] & 3 != 0" would print only TCP SYN and FIN 106 packets. 107 108 The most painful change is that concatenation no longer means 109 "and" -- e.g., you have to say "host foo and port bar" instead 110 of "host foo port bar". The up side to this down is that 111 repeated qualifiers can be omitted, making most filter 112 expressions shorter. E.g., you can now say "ip host foo and 113 (bar or baz)" to look at ip traffic between hosts foo and bar or 114 between hosts foo and baz. [The old way of saying this was "ip 115 host foo and (ip host bar or ip host baz)".] 116 117------------------------------ 118 119The program is loosely based on SMI's "etherfind" although none 120of the etherfind code remains. It was originally written by Van 121Jacobson, Lawrence Berkeley Laboratory, as part of an ongoing 122research project to investigate and improve tcp and internet 123gateway performance. The parts of the program originally taken 124from Sun's etherfind were later re-written by Steve McCanne of 125LBL. To insure that would be no vestige of proprietary code in 126tcpdump, Steve wrote these pieces from the specification given 127by the manual entry, with no access to the source of tcpdump or 128etherfind. 129 130The current versions of these files are available via anonymous 131ftp from host ftp.ee.lbl.gov (currently at address 128.3.254.68) 132file tcpdump.tar.Z (a compressed Unix tar file). 133 134This program is subject to the 'standard' Berkeley network software 135copyright: 136 137 Copyright (c) 1988-1990 The Regents of the University of California. 138 All rights reserved. 139 140 Redistribution and use in source and binary forms, with or without 141 modification, are permitted provided that: (1) source code distributions 142 retain the above copyright notice and this paragraph in its entirety, (2) 143 distributions including binary code include the above copyright notice and 144 this paragraph in its entirety in the documentation or other materials 145 provided with the distribution, and (3) all advertising materials mentioning 146 features or use of this software display the following acknowledgement: 147 ``This product includes software developed by the University of California, 148 Lawrence Berkeley Laboratory and its contributors.'' Neither the name of 149 the University nor the names of its contributors may be used to endorse 150 or promote products derived from this software without specific prior 151 written permission. 152 THIS SOFTWARE IS PROVIDED ``AS IS'' AND WITHOUT ANY EXPRESS OR IMPLIED 153 WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED WARRANTIES OF 154 MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. 155 156Enjoy. 157 158 - Van Jacobson, Steve McCanne, Craig Leres 159---------------------------- 160 161This directory also contains some short awk programs intended as 162examples of ways to reduce tcpdump data when you're tracking 163particular network problems: 164 165send-ack.awk 166 Simplifies the tcpdump trace for an ftp (or other unidirectional 167 tcp transfer). Since we assume that one host only sends and 168 the other only acks, all address information is left off and 169 we just note if the packet is a "send" or an "ack". 170 171 There is one output line per line of the original trace. 172 Field 1 is the packet time in decimal seconds, relative 173 to the start of the conversation. Field 2 is delta-time 174 from last packet. Field 3 is packet type/direction. 175 "Send" means data going from sender to receiver, "ack" 176 means an ack going from the receiver to the sender. A 177 preceding "*" indicates that the data is a retransmission. 178 A preceding "-" indicates a hole in the sequence space 179 (i.e., missing packet(s)), a "#" means an odd-size (not max 180 seg size) packet. Field 4 has the packet flags 181 (same format as raw trace). Field 5 is the sequence 182 number (start seq. num for sender, next expected seq number 183 for acks). The number in parens following an ack is 184 the delta-time from the first send of the packet to the 185 ack. A number in parens following a send is the 186 delta-time from the first send of the packet to the 187 current send (on duplicate packets only). Duplicate 188 sends or acks have a number in square brackets showing 189 the number of duplicates so far. 190 191 Here is a short sample from near the start of an ftp: 192 3.00 0.20 send . 512 193 3.20 0.20 ack . 1024 (0.20) 194 3.20 0.00 send P 1024 195 3.40 0.20 ack . 1536 (0.20) 196 3.80 0.40 * send . 0 (3.80) [2] 197 3.82 0.02 * ack . 1536 (0.62) [2] 198 Three seconds into the conversation, bytes 512 through 1023 199 were sent. 200ms later they were acked. Shortly thereafter 200 bytes 1024-1535 were sent and again acked after 200ms. 201 Then, for no apparent reason, 0-511 is retransmitted, 3.8 202 seconds after its initial send (the round trip time for this 203 ftp was 1sec, +-500ms). Since the receiver is expecting 204 1536, 1536 is re-acked when 0 arrives. 205 206packetdat.awk 207 Computes chunk summary data for an ftp (or similar 208 unidirectional tcp transfer). [A "chunk" refers to 209 a chunk of the sequence space -- essentially the packet 210 sequence number divided by the max segment size.] 211 212 A summary line is printed showing the number of chunks, 213 the number of packets it took to send that many chunks 214 (if there are no lost or duplicated packets, the number 215 of packets should equal the number of chunks) and the 216 number of acks. 217 218 Following the summary line is one line of information 219 per chunk. The line contains eight fields: 220 1 - the chunk number 221 2 - the start sequence number for this chunk 222 3 - time of first send 223 4 - time of last send 224 5 - time of first ack 225 6 - time of last ack 226 7 - number of times chunk was sent 227 8 - number of times chunk was acked 228 (all times are in decimal seconds, relative to the start 229 of the conversation.) 230 231 As an example, here is the first part of the output for 232 an ftp trace: 233 234 # 134 chunks. 536 packets sent. 508 acks. 235 1 1 0.00 5.80 0.20 0.20 4 1 236 2 513 0.28 6.20 0.40 0.40 4 1 237 3 1025 1.16 6.32 1.20 1.20 4 1 238 4 1561 1.86 15.00 2.00 2.00 6 1 239 5 2049 2.16 15.44 2.20 2.20 5 1 240 6 2585 2.64 16.44 2.80 2.80 5 1 241 7 3073 3.00 16.66 3.20 3.20 4 1 242 8 3609 3.20 17.24 3.40 5.82 4 11 243 9 4097 6.02 6.58 6.20 6.80 2 5 244 245 This says that 134 chunks were transfered (about 70K 246 since the average packet size was 512 bytes). It took 247 536 packets to transfer the data (i.e., on the average 248 each chunk was transmitted four times). Looking at, 249 say, chunk 4, we see it represents the 512 bytes of 250 sequence space from 1561 to 2048. It was first sent 251 1.86 seconds into the conversation. It was last 252 sent 15 seconds into the conversation and was sent 253 a total of 6 times (i.e., it was retransmitted every 254 2 seconds on the average). It was acked once, 140ms 255 after it first arrived. 256 257stime.awk 258atime.awk 259 Output one line per send or ack, respectively, in the form 260 <time> <seq. number> 261 where <time> is the time in seconds since the start of the 262 transfer and <seq. number> is the sequence number being sent 263 or acked. I typically plot this data looking for suspicious 264 patterns. 265 266 267The problem I was looking at was the bulk-data-transfer 268throughput of medium delay network paths (1-6 sec. round trip 269time) under typical DARPA Internet conditions. The trace of the 270ftp transfer of a large file was used as the raw data source. 271The method was: 272 273 - On a local host (but not the Sun running tcpdump), connect to 274 the remote ftp. 275 276 - On the monitor Sun, start the trace going. E.g., 277 tcpdump between local remote and port ftp-data >tracefile 278 279 - On local, do either a get or put of a large file (~500KB), 280 preferably to the null device (to minimize effects like 281 closing the receive window while waiting for a disk write). 282 283 - When tranfer is finished, stop tcpdump. Use awk to make up 284 two files of summary data (maxsize is the maximum packet size, 285 tracedata is the file of tcpdump tracedata): 286 awk -f send-ack.awk packetsize=avgsize tracedata >sa 287 awk -f packetdat.awk packetsize=avgsize tracedata >pd 288 289 - While the summary data files are printing, take a look at 290 how the transfer behaved: 291 awk -f stime.awk tracedata | xgraph 292 (90% of what you learn seems to happen in this step). 293 294 - Do all of the above steps several times, both directions, 295 at different times of day, with different protocol 296 implementations on the other end. 297 298 - Using one of the Unix data analysis packages (in my case, 299 S and Gary Perlman's Unix|Stat), spend a few months staring 300 at the data. 301 302 - Change something in the local protocol implementation and 303 redo the steps above. 304 305 - Once a week, tell your funding agent that you're discovering 306 wonderful things and you'll write up that research report 307 "real soon now". 308 309