CS330 - Fall 2025: Lab 3Observing Networks with Wireshark

Introduction§

In this assignment, you will use Wireshark [wikipedia], a packet sniffer and protocol analyzer, to capture and interpret frames transmitted on an ethernet link. Wireshark is an excellent open-source tool, with a highly usable interface and a wide range of capabilities. If you ever want to figure out what's happening on your network, Wireshark is probably the first tool you should pull out.

Because there can be security issues with a packet sniffer, capture packets only when and where you are asked to. If you would like to sniff other traffic, then PRIOR to sniffing, talk to me and get permission from all network users and administrators.

As a packet sniffer, Wireshark captures packets as they are being sent/received from/by your computer. Wireshark will store and/or display the contents of various protocol fields, as well as the payload, in the captured messages. This makes it an excellent tool for studying network protocols.

Wireshark is passive in that it observes messages being sent and received by applications and protocols running on your computer, but never sends packets itself. Similarly, received packets are never explicitly addressed to the packet sniffer. Instead, the packet sniffer receives copies of the packets, so the packets still make their way to the intended recipient.

A packet sniffer has two parts: a packet capture library and a packet analyzer. The packet capture library receives a copy of every link-layer frame that is sent from or received by your computer. Almost all Unix-based packet sniffers use libpcap. Capturing all link-layer frames gives you all messages that are sent or received by all protocols and applications executing in your computer. The packet analyzer helps you interpret the data collected by the packet capture library. It displays the contents of all fields within a protocol message. Thus, the packet analyzer must understand the structure of all messages exchanged by protocols.

Acknowledgments§

This assignment is adapted from "Lab: Wireshark: Ethernet" by Mike Erlinger at Harvey Mudd College. It also incorporates elements of exercises 1.1 - 1.2 in Computer Networking: Internet Protocols in Action by Jeanna Matthews (Wiley, 2005).

Goals§

To better understand the ethernet protocol by observing it in action.
To appreciate the "ecology" of a local area network.
To learn to use a packet sniffer.

Assignment§

Part A: Getting started with Wireshark§

Wireshark has been installed on the lab computers. Alternatively, you may download and install Wireshark on your own computer.
Download and open some sample capture files from the Wireshark wiki.
Explore the user interface. Wireshark has five major components:

Command menus : Standard pull-down menus located at the top of the window. File, Capture, and Statistics are of particular interest.

Toolbars : Near the top of the screen. Includes a Filter Toolbar (the text input area) that allows you to apply packet filters, so that only selected packets are displayed (e.g., those belonging to a particular protocol or from a particular sender).

Packet list : Displays a one-line summary for each packet captured, including a packet number assigned by Wireshark.

Packet details : In the lower left; provides details about the packet selected in the trace pane, "dissecting" it and presenting headers and data from the different layers of encapsulation.

Packet bytes : In the lower right; shows the entire contents of the captured frame, in both ASCII and hexidecimal.
Experiment with creating filters. This trace (from the Wireshark wiki) contains an HTTP transfer. Try these two different filter strings to exclude packets that are not related to HTTP:
- http
- tcp.port == 80
How do the packets you see differ? Form a hypothesis as to why there is a difference and include it in your report.
Close the trace file.

Part B: Capturing a filtered trace§

Sniffing is not allowed on the IWU network, so we will use Cloudlab in order to capture packets from a live network.

Use the CS330-F25-Lab3 profile to create an Cloudlab experiment with a single node and no links. Running this in Cloudlab gives you a way to run network sniffing software in an environment that allows its use. It should work on any Cloudlab cluster, but let's use the Wisconsin cluster this time (because... it's nearby? sure).
Log in to your node via SSH.
Wireshark isn't installed by default, so we need to install it. You are going to run the command-line version of Wireshark (without a GUI), called tshark ("t" for "terminal," I believe). We'll use apt, package-management software on certain Linux systems that makes installing and removing programs very easy. To install Wireshark (tshark), run:
```
sudo apt update
sudo apt install tshark
```
The sudo program lets you run programs as the Super User, or root, if you have the right permissions. For more information (sort of), see this xkcd classic. Whenever you are prompted to make a decision, press Enter to select the default choice.
Execute the following commands to capture a trace that includes fetching our favorite website in the world: www.ucd.ie

$ cd /tmp
$ sudo tshark -q -w 330lab3_trace &
$ wget http://www.ucd.ie/
$ fg
[press CTRL+C]

Explanation§

First, we change into the /tmp directory to be sure that we capture our trace in a file on the local machine. Your home directory may be mounted from a central Cloudlab server over the network. If you wrote your captured trace to your home directory, it would have to write the trace over the network, which would generate packets, which would be captured by tshark, which would be written to the trace over the network, which would generate packets... Exponential blowups are bad. But /tmp is guaranteed to be local to the node, not mounted over the network.
To capture packets, tshark must be run as root, which is accomplished by using sudo to run the command.
The -q option tells tshark to not output any statistics as it captures packets, and the -w option lets you specify a file in which to save the trace.
Ending the line with an ampersand makes the command run in the background. You then get another prompt from which you can execute further commands.
wget is a command-line program that performs web requests. It is extremely handy. I use it all the time. man wget if you're curious. And curl is another similar utility that is good to be aware of.
fg brings the tshark program back to the foreground so you can end it.
Pressing CTRL+C sends a signal to tshark telling it to stop capturing packets and quit.

Now your trace is saved in the file you created. To copy it to your own computer:
1. First, we have to get permission to access it. The capture file was created by tshark run as root (using sudo), so the file is owned by root, not your normal user. You can't access it as your normal user.
  - First, verify this for yourself by trying to look at the contents of the file:
```
cat /tmp/330lab3_trace
```
  - To change the permissions, run:
```
sudo chmod a+r /tmp/330lab3_trace
```
  - The chmod command changes permissions of a file. We have to run chmod as root to grant your regular (non-root) user access to the file. Giving chmod the a+r argument means "give all users read permissions." (Alternatively, you could just change the owner of the file to your regular user using chown. Either way works.)
2. Use scp on your own computer with USER@HOST:/tmp/330lab3_trace as the source path (see Cloudlab for the correct user and host strings) and . (the current local directory) as the destination path. Previously, you may have only used scp to copy files to Cloudlab. Copying in the other direction just involves making the remote path the source (first argument) and a local path the destination (second argument).
You can now open the trace you just transferred in Wireshark.
Don't forget to terminate your Cloudlab experiment when you're finished with it.

Part C: LAN ecology§

Using the trace you just captured, answer the following questions.

How much time elapsed during the trace? How many packets were captured? What was the average packet size? (Hint: Look under the Statistics menu.)
What protocols appear in the trace? Give the full name of each protocol along with the acronym. (Hint: Try sorting the packet list by protocol.)
Split the protocols into those you're familiar with and those you are not (just based on what we've learned so far). Briefly (one sentence each) describe each of the protocols you're familiar with. Research and do the same for at least two of the protocols you have not encountered before.
What is the IP address of the computer running the packet capture, and what is the IP address of the web server contacted by the wget command you ran? (Hint: Look at the IP header for the HTTP request or response.) What other IP addresses appear in the trace?
List any questions that you have about the traffic you see.

Part D: Ethernet§

Using the trace you just captured, answer the following questions. To limit the number of packets shown, use a filter to only show HTTP packets.

What is the ethernet address of the network interface on which you captured packets?
What is the destination address in the ethernet frame for the HTTP request? Whose address is this, the web server or a router? Why do you think so? How might you find out for sure?
Give the hexadecimal value for the two-byte frame type field in the ethernet frame. What effect does this field have / what is it used for?
Create a filter to filter out all ethernet frames that do not have your Cloudlab node's ethernet address as its source or destination. For example (change the address to match your node's address):
```
eth.src != c0:ea:e4:b1:b4:04 && eth.dst != c0:ea:e4:b1:b4:04
```
Why are some frames still listed? Explain for at least one of the frames listed why the node received that frame even though it didn't have the node's ethernet address as its destination address.

Part E: Ecology of another network§

Obtain a trace of another network via one of the two options below.

Using this new trace, address questions 1-3 from part C. How do the protocols seen on this other network compare to those you saw on the Cloudlab network? Can you make any inferences about the network configuration or hosts?

Option 1: Your own network§

Identify a network other than Cloudlab's that you have access to, and obtain permission from network users to capture packets. This does not need to be ethernet, but could instead be wireless, or even just a computer connected to a cable modem. I suggest a network in an off-campus house or apartment. This will let you easily identify all of the network users and obtain their permission.
Install Wireshark on your own computer.
In your lab report, record the location and type of the network.
Start a trace. Make sure you have selected the main network interface (ethernet or wifi) for the computer, not a loopback interface or something else. It should be an interface that carries most if not all of the network traffic for that computer.
Capture at least one minute and no more than five minutes. During this time, fetch a web page. If you like, do some more things to generate network traffic; note in the report what you did.
End the capture and save the trace file.

Option 2: A canned trace§

Download this sample capture file (only available from within IWU's network).

This trace was taken by me, at my home, on a machine connected to a small local network. I fetched a web page during the trace, and some other things were going on as well.

Submission§

Upload your network capture files from part B and part E (if you made your own for part E) separately from the lab report. The assignment will let you upload multiple files.

Discussion Questions§

The Cloudlab network is connected via ethernet. Is it connected via hubs or switches? How can you tell from the trace?
Many system administrators do not allow users to run packet sniffers on shared networks. Why do you think this is? How could this policy be enforced?
What traffic might you expect to find on a "quiet network," that is, one in which no user is deliberately using a network application such as a web browser? Consider both useful background activity and potentially malicious activity.
What internet radio station's website did I have open when I captured the trace I supplied for Part E?
Extra credit (a million points, plus a ton of money and/or a job with the NSA) : What is the password I used in the SSH session in the trace I supplied for Part E?
What did you find most surprising or interesting about this assignment?
How long did you spend on this assignment? What problems, if any, did you run into?