Wireshark is a network packet analyzer that intercepts, captures and logs information about packets passing through a network interface. This is useful for analyzing network problems, detecting network intrusions, network misuse, and other security problems, monitor usage and gather statistics, and many other applications.


System requirements for Wireshark are listed on http://www.wireshark.org/docs/wsug_html_chunked/ChIntroPlatforms.html

Windows and Mac OS X installers can be download at http://www.wireshark.org/download.html
Linux packages are available through the standard packaging system for most flavors of Linux.

Introduction Video


Getting Started

* You will need to run Wireshark with root/Administrator privileges in order to perform live capture on your network interface.

Start Wireshark. Under the “Capture” header, select the “Interface List” option; or click on the “Interfaces” button on the toolbar:
This will bring up a list of network interfaces that Wireshark is able to capture packets from:

List of available capture interfaces

Select the network adapter (wired or wireless) that you are currently using to connect to the Internet, and hit the “Start” button. This will take you to the main window:

Wireshark main window

Wireshark is now capturing live network activity on your network interface. Notice that the list of packets is color-coded to highlight different types of network traffic.
Open your web browser and navigate to a few random web pages – observe that the network packets corresponding to your web browsing activity are captured and show up in Wireshark as well.

By default, the list of captured packets will keep scrolling automatically during a live capture. You can toggle this on/off using the AutoScroll toggle button in the toolbar:

After letting the capture run for a couple of minutes, press the stop capture button:
Do not close this capture session yet!

Filtering the Packet List

In the previous section, we’ve captured all kinds of network traffic from a couple minutes of network activity – this could include traffic on many different protocols such as ARP, TCP, UDP, DNS, HTTP, etc.

We may not be interested in all of these, depending on what we are trying to achieve. Fortunately, Wireshark allows us to filter the list based on different criteria using the “Filter” toolbar:

Filter toolbar

For the purposes of this exercise, we are going to look at the HTTP traffic that occurs when we browse the web.

In the filter toolbar, type “http” and then click on “Apply”. The window will now list only captured packets related to HTTP traffic:

Displaying only HTTP traffic

You can display everything again by clicking “Clear” in the filter toolbar to clear the filter.

More complex filters can be built to filter traffic based on a variety of criteria by clicking the “Expression…” button.

Examining HTTP Traffic

Let’s take a closer look at the HTTP traffic that occurs during web browsing.

Let’s start with the HTTP request sent from your web browser.

Details of outgoing HTTP request corresponding to proxy.html

Now, let’s take a look at the HTTP response to the above request.

Details of incoming HTTP response corresponding to proxy.html

Data section of the HTTP response, containing the web page HTML

The requested web page contained a background image, which the web browser also had to fetch.

Now, repeat the exercise with the following links and observe the behavior of the corresponding requests and responses:

Filtering with Expressions

While we can easy to examine the traffic that occurs from browsing in a controlled environment as we have done above, things may be different in practice where there may be a large amount of traffic to sift through – simply isolating HTTP traffic may not be enough.
To locate specific packets related to individual requests or responses from a within larger capture containing more traffic, we can perform even more specific filtering using a variety of expressions relating to various header fields and their contents.

Start a new capture, and do some arbitrary web browsing, such as visiting some Wikipedia articles, reading some news, etc.
Then, with the capture still active, also visit all of the web pages we used in the last section:

Now, assuming we don’t have any prior knowledge about the order in which we visited various web pages, let’s filter the traffic using various expressions.

In the filter toolbar, click on the “Expression…” button. A dialog box will appear, showing a large list of possible packet header fields that can be used to filter the captured network traffic.
We are of course interested in particular to the options related to HTTP traffic:

Filter expression dialog: various expressions for filtering HTTP traffic

Let’s take a look at what some of these options do.

Among the first few field options are http.request and http.response. http.request allows us to filter the traffic so that only request packets are shown; conversely, using http.response displays only response packets.

Filtering only requests using the filter “http.request”

Other fields are more specific. For instance, recall the form that we submitted earlier – we can find the request corresponding to that by taking advantage of the fact that the form was submitted using the POST method:

Building an expression in the dialog: here we are looking for http.request.method of POST

After building the filter expression and pressing “Apply” on the filter toolbar, we obtain the HTTP request packet that we were looking for:

HTTP request packet corresponding to form submission using POST method

We can also look parts of URLs or whole URLs using http.host, http.request.uri and http.request.fulluri:

Filtering for requests to the host nunki.usc.edu

Filtering for URIs containing the substring “simple”

As well as the http.referer, such as in this case of a GIF image being loaded on simple2.html:

Filtering request generated by the referring page simple2.html

What about response packets?

Recall that we visited the URL http://www-scf.usc.edu/~csci571/missingfile.html, which returned a HTTP 404 response since there is actually no page at that location.
We can find the HTTP response that corresponds to that by filtering on the HTTP response code:

Building filter for HTTP 404 responses

Applying this filter, we are able to obtain the HTTP response packet that we were looking for:

HTTP response corresponding to attempt to visit an inexistent page

Other fields that can be used to filter for specific response packets include the http.content_type, http.content_length, http.last_modified, http.server, etc.

You can even combine multiple expressions using logical operators to form more complex filter patterns:

and :&&
or :||
xor :^^
not :!

In the following example, we build a filter to look for a HTTP response that served up a GIF image from a web server running Apache:

Using logical operators

Further documentation about building display filter expressions can be found in the Wireshark online documentation at http://www.wireshark.org/docs/wsug_html_chunked/ChWorkBuildDisplayFilterSection.html

A comprehensive list of all the possible http header fields that can be used for filtering is available at: http://www.wireshark.org/docs/dfref/h/http.html

Appendix: Bad packets (False negatives from checksum offloading)

If you see a large number of bad packets (highlighted with red text on black background) among the captured packets in your main window, this may not actually reflect a large number of bad packets, but may be a known issue related to IP “checksum offload”.

Checksum offload is a mechanism whereby the calculation of the checksum for outgoing packets is “offloaded” (outsourced) to the driver for the network interface instead of being calculated by the OS. Consequently, the packet does not have the correct checksum yet when Wireshark captures it, and gets highlighted due to the discrepancy. This is a purely cosmetic error since the correct checksum will indeed be calculated and included with the packet when it is transmitted over the network.

To determine if the bad packets that you see are a result of this, pick a bad packet and examine the information related to the offending header (highlighted in red):

A packet with “incorrect” IP header checksum caused by checksum offloading

To make this error go away, you can disable IP checksum validation as follows:

The same can be done for other protocols (TCP, UDP, etc) if you find that they are affected by this same issue.