Getting Started with WireShark

This article presents WireShark, a very capable and popular graphical network protocol analyser.

Gerald Combs created Ethereal, the ancestor of WireShark, back in 2006. When he changed his job, he could not use the name Ethereal any more, so he renamed his software WireShark. Nowadays, most people only know WireShark! The main advantage of WireShark is that it is a graphical application. There is also a command-line version of WireShark but I have never used it.
You can get WireShark either from its website by compiling its source code or directly from your Linux distribution. I personally prefer the second option.

Running WireShark

If you try to run WireShark as a normal user, you may not be able to use network interfaces for capturing network traffic, due to reasons related to UNIX permissions. Run WireShark as the root (sudo wireshark) when capturing data, and as a normal user when analysing network data. Figure 1 shows WireShark run by a user without root privileges.
Before going into more details about WireShark, I have to talk about network traffic in Ethernet networks that use the TCP/IP family of protocols. When we say TCP/IP, we not only mean the TCP and IP protocols, but many other protocols including ARP, BOOTP, UDP, ICMP, FTP, etc. Information is transferred using packets. Each packet has a header and a body part. The header part contains information that is needed by the protocol, whereas the body part contains the data. Some protocols are reliable, whereas others are not, which means they do not guarantee package delivery this is not always a problem, but the application must deal with it, if required.

WireShark captures packets, and analyses and displays them in a human-readable format. WireShark allows you to follow a TCP/IP conversation between two machines, view packet data, etc. Before you start capturing, it is better to have in mind a particular issue that you want to solve or examine. What follows are the initial steps towards successful network traffic analysis.
Basic usage

After running WireShark with the required user privileges, you will be able to see the list of available network interfaces. The easiest way to start capturing network packages is to click your preferred interface, which will make WireShark immediately start capturing network packets (Figure 2). If you know nothing about TCP, IP or UDP, you may find the output confusing. To stop capturing, select Capture and then Stop from the WireShark menu. Alternatively, press the fourth icon from the left, with the white x in a red background, which is only active during captures.

Using the method described for capturing, you cannot change any of the default WireShark capture options (viewable by selecting Capture and Options from the menu as shown in Figure 3). There you can select the Interface (en0), see your IP address (192.168.1.10), apply any Capture Filter (in the image, there is none), put your network card in promiscuous mode, and save captured data to one or more files. When capturing lots of data, it is considered a good practice to first save and then examine captured network traffic. When you put your network card in promiscuous mode, you allow the network device to catch and read every network packet that arrives, even if the receiver is another device on the network. You can also choose to stop packet capturing after a given number of network packets, a given period of time, or a given amount of data (in bytes).

WireShark allows you to read and analyse captured network data from a large number of file formats including tcpdump, libpcap, Sun’s snoop, HP’s nettl, K12 text file, etc. This means that you can read almost every kind of captured network data with WireShark, while new file formats are frequently added. It is more likely that WireShark cannot read a file due to invalid packet types than an incompatible format! Similarly, WireShark allows saving captured network data in a variety of formats, visible in Figure 4. You can even use WireShark to convert a file from one format to another.

WireShark display filters
The amount of network data that WireShark may display can be too much for a human to watch and understand, especially on very busy networks. Usually, when using WireShark, we want to examine a given problem or situation, or even watch for unusual network activity. WireShark allows us to filter network data for specific types of traffic during capture, avoiding creating huge capture files but there are also display filters, which tell WireShark to display packets that really matter, while capturing everything, so that you look at fewer packets and easily find what you want.
Generally speaking, display filters are considered more practical and versatile than capture filters, because most of the time, you don’t know in advance what you want to examine. Nevertheless, using capture filters can save time and disk space; that is the main reason for using them.

WireShark tells you when a Display Filter is syntactically correct when the background turns light green, then the filter is syntactically correct; and when the syntax is erroneous, the background is pink. You can see both cases in Figure 5. The result of a logically inaccurate (yet syntactically correct) filter at capture time is no captured data so you may recognise this error the hard way.
What you can also notice in Figure 5 is that WireShark is smart enough to understand erroneous IP addresses such as 192.168.257.10. The presented display filter shows only traffic that originates from, or goes to, the 192.168.1.10 IP address.
 Note: Display filters do not magically solve problems by themselves. They are extremely useful tools when used the right way, but you still have to interpret the results, find the problem and think about the solutions.

Analysing DHCP traffic
DHCP (Dynamic Host Configuration Protocol) provides configuration information to hosts on TCP/IP networks. It is based on BOOTP (the Bootstrap Protocol) and extends it by adding more capabilities. DHCP and BOOTP both use UDP (ports 67 and 68). DHCP supports, among others, the following basic messages:
DHCPDISCOVER: Clients searching for a DHCP server send this broadcast message to the LAN, using only the client MAC address, because the client does not have an IP address yet.
DHCPOFFER: When a DHCP server receives a DHCPDISCOVER message, it responds with a DHCPOFFER message.
DHCPREQUEST: The DHCPREQUEST message provides information to the chosen DHCP server, even if there is only one available.
DHCPACK: This message is the response of the chosen DHCP server. It includes all the required configuration information.
Figure 6 shows a DHCP transaction that involves the airport wireless card of an iMac and an ADSL router that also acts as a DHCP server. Please notice how much easier it is to see the DHCP protocol when using the right Display Filter (bootp).
The first packet is the DHCPDISCOVER message from the iMac searching for a DHCP server. Since the iMac does not have an IP address yet, the source IP of the packet is 0.0.0.0 and the destination IP is the broadcast IP (255.255.255.255). What distinguishes the airport card of the iMac from the other network devices found in the same LAN is the MAC address of the airport card, which is unique. Therefore, the DHCPDISCOVER message should include the MAC address of the device requesting a DHCP server.
The next message is the DHCPOFFER from the DHCP server with IP 192.168.1.1, and is a broadcast message, since the iMac still has no IP address. Then the iMac requests the DHCP server for the offered configuration parameters with the DHCPREQUEST message. Next, the DHCP server sends a DHCPACK message back to the iMac that includes the configuration parameters. From now on, the iMac can use the offered configuration information and any parameter that is unique to the iMac, like the IP address, is reserved by the DHCP server and is not offered to any other device.
WireShark is a powerful tool that every Linux or network administrator should know. I suggest that you first start by learning display filters before going any further. As always, before trying to solve a complex problem, first try to address simpler or smaller issues.

Web links and bibliography
[1]     WireShark: http://www.wireshark.org/
[2]     Tcpdump and libpcap site: http://www.tcpdump.org/
[3]     Internetworking with TCP/IP, Volume I, Douglas E. Comer, Prentice Hall
[4]     DHCP RFC: http://www.ietf.org/rfc/rfc2131.txt
[5]     Display Filters Reference: http://www.wireshark.org/docs/dfref/
[6]     The TCP protocol RFC: http://www.ietf.org/rfc/rfc793.txt
[7]    The UDP protocol RFC: http://www.ietf.org/rfc/rfc768.txt