This is a short tutorial on tcpdump. You must make a printout of ``man tcpdump'' to follow this tutorial. Note: ``man tcpdump'' will be (slightly) different on different computers. You must be root to use tcpdump, but anybody can get man tcpdump. The examples I use were obtained in the Internet Lab, GITC 4325, on 03/12/2005. Three computers were used: franklin, marconi, and hawking (which should have been hawkings). Marconi is configured as a router. Franklin and hawking are configured as hosts. Traffic between franklin and hawking passes through marconi. I created a small file called ``twopackets'' in franklin. It is about 1536 bytes large, so when ftp-ed it needs two packets. I turned on tcpdump in marconi on the interface toward franklin. I let tcpdump ``dump'' a copy of every packet it saw, without analyzing the packets, into a file. The command was: tcpdump -s 0 -i eth3 -w rawtwopack I then ftp-ed the file ``twopackets'' from franklin to hawking, and then turned tcpdump off in marconi. (Control-C). See Forouzan Ch 19 for a description of FTP. It uses two TCP flows, one for ``control'' and one for ``transport''. The file ``rawtwopacks'' in marconi is not human-readable. I made four different ``human readable'' versions of it, by the commands tcpdump -r rawtwopack -s 0 -e -vvv > cooked1twopack tcpdump -r rawtwopack -s 0 -e -n -nn -S > cooked2twopack tcpdump -r rawtwopack -s 0 -e -n -nn -S -x > cooked3twopack tcpdump -r rawtwopack -s 0 -e -n -nn -S -x -X > cooked4twopack Read ``man tcpdump'' and try to figure out what the four files cooked1twopack, cooked2twopack, cooked3twopack, cooked4twopack contain. For the time being I will only show you cooked1twopack, cooked2twopack, cooked3twopack. (on this page). Note: while they are ``human readable'' they are pretty nasty to read for us humans! Among other things, in the first two every packet is one long line, without any space between the lines. I wrote the Perlscripts ``addwhite'' which adds white between lines, ``breaklines'' which breaks lines, and ``clean'' which removes space from the end of lines. These scripts are on this page. Feel free to use them. Do not forget to make them executable. (chmod 777). To debug I did ( >: stands for the prompt) >: ./addwhite cooked1twopack > interm1.1 >: ./breaklines interm1.1 > interm1.2 >: ./breaklines interm1.2 > interm1.3 >: ./clean interm1.3 > interm1.4 Of course, when everything worked I combined the three scripts into a single shellscript ``doit'' which consists of the line addwhite cooked1twopack | breaklines | breaklines | clean which is executed as >: ./doit > clean1twopack Don't forget to make doit executable (chmod 777). You can see I am a lousy programmer. I have to put the name of the input file cooked1twopack inside the script doit , and I did not have ``.'' in my path! I am sure all students will do better. After the fact: from looking at the resulting file clean1twopack I realize I should have used ``breaklines'' a third time. ``doit'' should be addwhite cooked1twopack | breaklines | breaklines | breaklines | clean Similarly, create clean2twopack and clean3twopack . (That is homework). Now follows a short explanation of the output in the file ``clean1twopack''. You should have seen by now that because cooked1twopack was created NOT using the options -n or -nn , the computer ``often'' gives the names of ports (etc), instead of numbers. ----- Packet 1: was seen on 03/12/2005, at time 16:23:02.184419 (16 hours, 23 minutes, 2 seconds and 184419 microseconds). tcpdump uses a 24 hour clock! It is a packet from physical address 0:2:b3:d3:d4:8a to the broadcast address. It is an arp packet. (from ethertype). It is 60 bytes long. That excludes ``pre-amble'' and CRC. Ethernet padding is a bit of a problem: it is included for ``incoming'' packets, but excluded for ``outgoing'' packets. This packet asks: ``who has internet address 10.13.0.2'' ? Please tell the host with internet address 10.13.0.1 ! Packet 2: Time 16:23:02.184461 Since I tell you that marconi and franklin are on the same net, you now know that franklin is 0:2:b3:d3:d4:8a , 10.13.0.1 and that the interface of marconi toward franklin is 0:2:b3:cd:cd:c8 , 10.13.0.2 . Packets 1 and 2 enable franklin to put marconi in its arp cache. Packet 3 is a dns request from franklin to the dns server in the lab to give it the address of hawking. Packet 4 (16:23:02.186003) is the response of the dns server (kirk), explaining that hawking is 10.14.0.1. (kirk is 10.3.0.254). Packet 5 is a TCP packet! It is the ``Original SYN'' from franklin to hawking, for the control channel. It uses port 55657 on franklin and ``the ftp port'' on hawking. (in the file from cooked2twopack we see that the ftp control port is port 21: agrees with Forouzan.) Packet 6 (16:23:02.187258) is the SYN-ACK from hawking to franklin. Packet 7 (16:23:02.187385) is the ACK from franklin to hawking. etc. Please note that most of those packets have the DF bit set. (Do not Fragment). Several have the Push bit set (P). At time 16:23:09.412729 there is a confusing packet. This is the ethernet switch letting computers know it is there. Finally, at time 16:23:34.387070 there is the original SYN packet of the transport flow! It uses port 55664 on franklin and port 29547 on hawking. You see, Forouzan Chapter 19 is wrong! (Forouzan says the control channel uses port 21 in the server and the transport channel uses port 20 in the server). Homework: Find the SYN-ACK and ACK for this three-way handshake. At time 16:23:34.390083 there is the first FIN for the transport flow. Note: at time 16:23:34.390537 there is an Ack in the opposite direction, but it does NOT acknowledge the FIN! It acknowledges some older data. At time 16:23:34.390542 the data ``before the FIN'' is acknowledged. At time 16:23:34.390602 the first FIN itself is acknowledged. It seems that indeed the ack number in increased by one. But in obtaining this file I did not use the option -S , so after the SYN and SYN-ACK we do not get the raw Sequence Numbers and Ack Sequence numbers, but the offsets, so it is not clear exactly what happens. Homework: Find all FINs and their corresponding ACKs in this output. ----- Homework: Create the files clean2twopack and clean3twopack. (Exactly the same packets, other representation). Look them through. Remember: the differences are due to the fact that for these files I used -n and -nn and -S. See everything makes sense. Homework: Find out exactly what happens with Seq number and AckSeq number during ``SYN episodes'' and ``FIN episodes''. clean3twopack (from cooked3twopack) contains a complete copy of every packet. Headers, data, everything. In hexadecimal. You can use Forouzan Appendix A (p 771) to translate hexadecimal to ascii. (Or go to the web and find a program that does it.). Homework: From the control channel, find the login and password I use inside the lab. (Different from outside the lab). Note: if you even TRY to find somebody else's password outside the lab you will be terminated. Homework: Find (reconstruct) the file I FTP-ed from franklin to hawking. Finally having fun! Teun Ott. --- Added on 03/25/2005. Apologies for the delay. I have been out with a bad cold. There WILL be class on 03/26/2005! I added a diagram of part of the Internet Laboratory Network, to clarify the tcpdump outputs. I added ``very clean'' versions of cooked2twopack and cooked3twopack. (By modufying ``doit'' so it does ``breaklines'' three times instead of two times.) Please have with you, in class on 03/26/2005, copies of the files ``networkdiagram'', ``extra clean file for cooked2'', and ``extra clean file for cooked3''. Also, please bring a copy of the ``Short FTP example'' in my general CIS 656 Spring 2005 page.