Here's part two - just finished writing it up for my trainee geeks at work As before, let me know if you have questions or want any help with it. Capture Analysis In the first part of this tutorial we saw how to install Ethereal, configure your interfaces and begin capturing data. This part of the tutorial will cover the basics of analysing your capture files, giving you a basic understanding of how to use the interface, what each window shows and providing pointers to further learning. In the final part of the tutorial, Ill show you how to analyse a capture of something a little more exciting than the PING probe you made earlier. For now, lets stick with the PING capture you performed in the first part of the tutorial. Providing you followed my advice and stopped capturing straight after your PING probe was complete, you should have no difficulty locating the packets that represent the PING session they will be at, or near the bottom of the uppermost pane in the Ethereal interface. Helpfully, youll notice that Ethereal colour-codes packets according to protocol. Your colour for ICMP packets may be different, but as you can see, mine is a lovely shade of violet. The Ethereal interface Before we go any further, lets take a closer look at the Ethereal interface so you can familiarise yourself with the different elements it contains. Right at the top of the screen is the traditional menu bar, with the equally traditional toolbar situated just underneath it. These contain commands & options just like any other program. Directly underneath the tool bar there is a series of three windows, displaying the data you have captured. The top window is called the Summary Window. This displays a single-line summary of each packet captured by the program. Underneath this is the Protocol Tree Window which displays the packet in much more detail. The final pane is the Data View Window. This is where the raw data comprising the packet is displayed. OK with that explanation out of the way, on with the analysis. Understanding the analysis procedure To begin with, lets examine the first packet that represents the start of your PING session. (Now dont get pedantic, I know that there are probably two ARP packets directly above requesting the MAC address of the IP you pinged that represent the REAL start of the PING probe but were only interested in the actual ICMP packets themselves at the minute but give yourself a pat on the back if you were about to raise an objection, it shows you understand basic networking!) If you highlight the first packet in your PING session by clicking on the row representing it in the Summary Window, youll see this packet turns a dark blue colour alerting you to the fact that it has been selected. Youll also notice the Protocol Tree Window now shows a different set of data than it did this is the packet information for the first packet in your PING probe. This is where the meat of the information about the particular packet being examined is located. Whilst the Summary Window provides you with a basic idea of what a particular packet contains, the Protocol Tree Window shows you all the information contained in the packet, including headers, protocol information and payload. So lets take a closer look at the Protocol Tree Window. All packets contain a set of information that both describes the packet and the data it contains. This information varies from protocol to protocol, but can contain things such as a sequence number, date/time information, source address, destination address, protocol type, MAC addresses and any of a whole host of other things as well as the data itself. This can make the process of examining each packet a pretty complex and time-consuming task. Luckily, weve chosen an ICMP packet here, which are relatively easy to understand. The easiest way to look at the Protocol Tree Window is to see each packet as a collection of fields and subfields. Youll see the + signs on the left-hand side if you expand one of these youll find information related to the particular element of the packet that it represents. In our case, the following elements are present: The packets descriptive data, or Meta Data This is data that describes the packet and includes Time/Data received, the Frame number, Frame length and a list of the protocols contained within the frame. In the case of this capture, we can see that the Frame Number is 17, that it was transmitted on August 11th at 21:47:26, it is 74 bytes and that the entire frame was captured (74 bytes on wire, 74 bytes captured). Note here that sometimes not all data in a packet is captured, for various reasons. Looking at the MetaData frame is a good way to ensure you have captured the entire packet. A brief note is necessary here on the layered methodology of network communications. Youll recall from your basic networking training that network communication is a layered affair. Ethereal adopts a top-down approach to displaying the data at various layers of the OSI model with the top entry in each packet captured being the lowest level of information (the DataLink layer), rising to the highest layer (the Application layer). Since the Packet MetaData is not part of the actual packet it just describes it this information should not be considered part of the packet capture itself The DataLink (Layer 2) information Underneath the MetaData information is the information pertaining to the DataLink layer which, as any student of the OSI model knows, is the layer representing physical assembly of packets on the wire. In our case, this is the Ethernet II standard you may also see other types such as Token Ring & FDDI, but the vast majority of the time you will be capturing over Ethernet. As you can see, expanding this layer in our capture shows two more expandable entries one designating the Destination address, the other showing the Source address. This is an excellent example of the hierarchical nature of Ethereal to begin with, all you can see for each entry is the description of the interface and its MAC address, but if you expand the node you will see more information. In this case it isnt that much more exciting just letting you know that the frame is a Unicast frame as opposed to a Broadcast or Multicast. It does, however, serve to highlight that there can be information in a capture that isnt immediately apparent. Always expand the + signs! The Network Layer (Layer 3) information Now we start to see something a little more worthy of analysis. Since the Network layer protocol is much more interesting than the DataLink layer, there is much more information to be found here. For instance, we see that the Layer 3 protocol in use here is the Internet Protocol (IP). We can deduce from our capture that the two IP addresses assigned to the source & destination addresses are 192.168.1.154 and 192.168.1.10 respectively. We can also see that none of the various flags available in IP have been set, and that the TTL is set to 128. Finally, we note that the protocol that the IP encapsulates is, in this case, ICMP. As you can see, there is far more to see in this layer. The Network layer information is often extremely revealing and investigation of this particular area of a packet can often lead to diagnosing the cause of network errors and discovering & analysing unauthorised network access (e.g. from Trojans) Since ICMP is not actually a part of the Network Layer, but is a feature of the IP protocol, it is displayed below in a separate entry. You can see here the information relating to the ping probe itself ever wanted to know what type a PING request was in ICMP? Now you know type 8! You can also see here that the PING was assembled correctly, and view the Sequence Number this could be very handy for seeing whether transmissions are being received out of order. Other Layers (Layer 4 and above) Since our capture here is just to illustrate the features of Ethereal and demonstrate how to use it, we havent got anything more exciting to look at. However, above Layer 3 sit the higher levels of the stack Transport, Session, presentation and Application. In the final part of the tutorial, well look at capturing an HTTP request, where data pertaining to more layers of the stack will be captured. For now though, this concludes the information to be found in the Protocol Tree Window. In the final part of this tutorial well look at the raw data that makes up the packet itself. Raw Data As you know, computers deal in raw data. The Data Window allows you to take a peek at the actual raw data making up a packet. If you highlight any of the rows in the Protocol Tree Window, you will see, in the bottom pane of Ethereals interface, the raw data comprising that information. This will not often be easy to understand to use a good example, lets look at the actual raw data of the PING request. If you highlight the Data field in the ICMP tree within the Protocol Tree Window, you will see the raw data pertaining to this data in the Data View Window. As you can see a series of Hexadecimal numbers is highlighted. This is the actual data of the 32 byte data field within the ICMP PING request. If you look to the right, you will see the data (again highlighted for you) represented in ASCII format. Did you know that PING requests contained a series of 32 characters in ascending order? Now you do! That pretty much concludes the basic overview of capture analysis. If you want to, go ahead and have a look at the other packets ion the PING session, and play around with looking at other types of packets you may have captured. In the final tutorial well look at a capture which is more useful practically than a simple PING probe.