TCPdump is a package on Unix computers that allows you to make a trace of all packets seen on the ethernet (or FDDI, etc) connected to the Unix host. There are similar packages for PCs (packages called Snoop and similar names). I have put two such traces on my website: trace_all.txt and trace_tcp.txt . I have modified the layout for easy reading. 1. trace_all.txt This trace was taken on 04.01.2002 shortly before 6:00 pm. The first packet is time stamped 54 minutes, 13 seconds, and 735097 microseconds after 17:00. The last packet is timestamped 54 minutes, 17 seconds, and 392244 microseconds after 17:00. This trace is a trace of most packets seen by tcpdump. I only filtered out the dns packets. (There are too many of these). Each packet has: Time stamp. (See above). Source ethernet address and destination ethernet address. Ethertype Size of ethernet packet. (Excludes Pre-amble, SFD, and CRC). and more, depends on type of packet. The first packet shown is a UDP packet. line 1: ethertype = 0800 (IP v4), ethernet packet = 62 bytes. further: from host 128.235.32.5, UDP port 1985, to "host" 224.0.0.2, UDP port 1985. There are 20 UDP data bytes. TTL = 2, ID = 0, Total length of the IP packet = 48 bytes. (Check: IP header = 20 bytes, UDP header = 8 bytes, UDP data = 20 bytes, 48 + 6 + 6 + 2 = 62). The second packet is an ARL Request. Note that the ethernet destination address is FF:FF:FF:FF:FF:FF, i.e. 48 ones, i.e. the ethernet broadcast address. The seventh packet is a RIP (Routing Information Protocol) version 1 packet. See Forouzan Ch 13. So, NJIT uses RIPv1 for routing! For further explanations, see ``man tcpdump'' on any Unix Host. Homework: Use nslookup to find out more about the "host" 224.0.0.2 . Check this with what you learned in class. 2. trace_tcp.txt This trace was taken between 19:03:41.184460 and 19:06:50.930061 on 04/01/2002. All packets other than tcp packets are filtered out. During this period I did a small download of a web page (one of my own web pages) from www-proxy.njit.edu to maan.njit.edu . (for short: between proxy and maan). Packet number 5 is the first SYN from maan to proxy. Note the destination port number is 80: http . maan gives its receive window as 24820 bytes. It tells proxy it can handle SACK (selective acknowledgements) and suggests an MSS of 1460 bytes. This packet does not contain data (it contains all bytes ``in between'' 2141146493 and 2141146493, i.e. 0 bytes). It does not acknowledge any data. (Hence, the Ack flag must be zero). Maan uses TCP port number 47556. Packet number 6 is the responding SYN-ACK from proxy to maan. It contains no data, but gives the intial sequence number. It does acknowledge (next expected = 2141146494). It confirms MSS = 1460 and tells maan also proxy can handle SACK. After these two SYN packets, acknowledgement numbers and sequence numbers are offset by the initial sequence numbers, and sequence numbers are given only when there actually are data bytes. This is a peculiarity of the specific version of tcpdump. Packet number 7 is the acknowledgment from maan to proxy for packet numer 6. It contains no data. Packet number 8 is again a packet from maan to proxy. It contains 350 data bytes. Note that all packets have the DF bit set. Compare packets 10 and 12. The bytes numbered 1461 - 2920 are missing from the flow from proxy to maan. Also check packet identification numbers. The packet with identifier 38632 is missing. Packet number 13 (timestamp: 19:03:41.628234) has an option, which causes the tcp header to extend past the bytes monitored by tcpdump. Hence [|tcp] (see man tcpdump). This is a duplicate acknowledgement (compare with packet 11, see remark above). It is likely the SACK option is used by maan to tell proxy what data seems to be missing. (I have forgotten the details of SACK). Packet number 18 is the re-transmission from proxy to maan of the missing data (bytes numbered 1461 - 2920). Packet number 20 (timestamp: 19:03:41.796084) is from maan to proxy, but has a different source port number (47541): this is a packet of a different flow! (That already existed before packet 5). That flow is terminated in packets 21, 22, 23. In packets 24 - 26 a new TCP flow between maan and proxy is opened. At maan this new flow uses TCP port 47557 (the next free number). The flow to port 47556 still exists! (Is not terminated at all during this tcpdump trace). Between 19:03:43.194218 and 19:03:194953 this new TCP connection is closed, and immediately after a new one is opened. This pattern repeats itself a couple of times. Etc. Homework: Study the next packet headers. Use ``man tcpdump'' whenever you do not understand something. What is the largest number of simultaneously open TCP connections between maan and proxy that you know of? How many ``good'' data bytes are transported from proxy TCP port 80 to maan TCP port 47562 during the time interval of this trace? When is that flow opened? When is it closed?