CSE 461: Introduction to Computer-Communication Networks, Winter 2010
  CSE Home   About Us   Search   Contact Info 
 
Course Home
  Home
Administation
  Overview
  Using course email
  Email archive
  Anonymous feedback
  View feedback
 
Assignment Utilities
  Homework Turnin
  Assignment Wiki
  Gradebook
  Discussion: Protocol Bert
  Discussion: Protocol Ernie
  Discussion: Protocol Elmo
 
Most Everything
  Schedule
    Homework 3
Out: Thursday February 11
Due: Wednesday February 17, 11:59PM
Turnin: Online

The required portion of this assignment is very small. It's so small that you should easily be able to complete it even if you don't start until after the long weekend.

Real Traffic, Real Tools

You're given a very small log of network traffic from a very small private network, and a tool that can read the log and display the packet traffic in convenient form. The log was taken while a Fedora 11 machine booted. You're asked some questions about that machine and the network it's on. Those questions can be answered by manually looking over the log.

Useful general information: There are many tools to both capture packets off the network and to convert them to a (more or less) human readable form. The best known of these is tcpdump, which is a command line utility. tcpdump can capture packets off the network. tcpdump also defines a file format for captured packet logs. Finally, it has commands that allow filtering of logs, based on things like source or destination IP address, or protocol family (e.g., UDP or TCP).

The tool actually used to capture the specific log we'll look at, and our default choice for examining it, is Wireshark. You might think of it as tcpdump with a gui. Wireshark runs on Windows, OS X, and many other varieties of Unix, including Linux. The twin goals of this assignment are to reinforce a bit of the recent lecture material and to introduce you to the general class of network traffic capture programs and Wireshark in particular. Wireshark (or the like) could be very handy some time in the future, in life beyond CSE 461.

Using the Trace and Wireshark

The log file captured 229 packets from the network. The trace was run on a machine with a wired, 1Gbps Ethernet connection. (Both the 'wired' and '1Gbps Ethernet' portions of that information tell you things that are pertinent to what you might expect to see in the log, which is why I'm mentioning them. On the other hand, they're not so pertinent that you need to know them to answer the actual assignment questions.)

When you run Wireshark and open the log file, you'll see a display like this:

Obviously, the interface is bristling with features. You don't need very many at all, though. Doing obvious things (like trying the scroll bar to see later parts of the trace) is pretty much it. (As another example, one of those obvious things is opening the log file.) Like all packet trace software, Wireshark is oriented towards big traces -- hundreds of thousands of packets, or larger. You don't need nearly any of its features because our problem is so small.

The experience of figuring out what Wireshark is showing you, and how to do the things you need to do, is an intended part of the homework experience.

Mechanics

Wireshark

It's installed on attu and the lab Linux workstations at /usr/sbin/wireshark. Launch it from the command line. Select "Open" on the screen that appears to open the log file.

Note: Do NOT just issue the command 'wireshark.' That will launch a version that will fail (on an insufficient privileges problem).

Log File

It's here.

The Questions

Turn in a single file that contains your answers to the following questions, which can be answered by the information in the packet trace file.
  1. As mentioned earlier, a Fedora 11 machine boots during the time the trace is being taken. What is the IP address of that machine?

  2. From what machine does the Fedora machine obtain its IP address? (Identify the machine by giving its IP address.)

  3. There is a single gateway (to the Internet) on this network. What is its address?

  4. Besides the IP addresses you've identified in the previous questions, what other IP addresses on the same (local) network are you certain were in use during the period of the trace?

  5. How many distinct "machines" do you think were active on the local network during the period of the trace? Here by "machine" I mean a box -- something you could pick up and walk off with. (Note that I wouldn't be asking this if it were purely clerical work figuring out the answer. There are two distinct reasons why it's not just clerical work, but only one of them is a 461 topic at all. If you find that one, you're done. (I'm mentioning that there are two because someone is likely to find the non-461 one first, even though it's not required to find it at all.))

  6. What does the trace tell you about how many Ethernet bridges there are gluing together the local network?

  7. OPTIONAL As best you can, guess what kind of thing each physical box is. (Okay, now that's vague. But, it's optional. Try to answer it only if you like this sleuthing through the log. It's worth no points.)
These questions have been asked in a way that promotes short answers (e.g., '2'), and doesn't ask for explanations. Grading will necessarily be along the lines of right or wrong. (Questions 5 and 6 have more than one right answer. The reason: there is an expected answer, based on what we've covered in class. Some people may know more than what we've covered though, and that might lead to slightly different conclusions.) This assignment won't carry huge weight toward the final grade.

Optional (Recreational Interest Only) Part 1

Wireshark is useful. If you find looking at logs interesting, you might want to try playing around with it yourself.

To capture logs requires root access (at least on Linux; I'm not sure what privilege is required on Windows). Fooling around with Wireshark is therefore best done using one of your own machines.

To capture a trace, install Wireshark on your machine and then launch it as root (or equivalent). Click on the leftmost icon in the toolbar full of icons (shown in the picture above). A dialog appears that lists the available network interfaces. A name like eth0 is a wired ethernet adapter. There is more than one name for wireless adapters, but a likely one is ath0. (Another possibility is wlan0 or something similar.) One of the choices in the dialog is "all interfaces," which is a good first choice if you're just trying things out.

Packets will now start appearing in the main window. You can stop capture by hitting the icon three to the right on the one you used to start things up. (All these icons have tool tips, by the way.) You can save the trace to a file using the File menu.

If your trace is long, you might want to filter packets. The syntax for this is arcane. Basically, you can filter on fields of protcol headers. There are a lot of protocols, and a lot of fields. The Expression button to the right of the Filter text box (shown in the picture above) is a big help. Still, it's hard to use unless you're very familiar with the protocol and the header data it uses. The Wireshark documentation page is here, and the page(s) about filtering is here. Be forewarned that you're going to have to be pretty motivated to do filtering, though. (One tip: filtering on IP is pretty easy, e.g., "ip.addr == 192.168.0.1").

You can also do more useful things that simple filtering, e.g., follow a TCP conversation. (What that means is ahead of where we are in the course, though.)

I definitely think it's worth trying out capturing a trace, if you're at all interested. Later, when you need a trace to solve some problem, you can puzzle out the filter expressions (and other interface features) that you need, given that motivation.

Optional (Recreational) Part 2

If you want to snoop around in a longer log, there's one here.

This is a 175K packet trace taken over about 40 minutes by my netbook during the midterm. It's a wireless trace, meaning it's certain that the netbook has missed many packets that were in the air (i.e., the trace is incomplete).

Do not distribute this trace, due to privacy concerns. On the one hand, anyone, at any time, can be sniffing packets off the air, so it would be mistake to assume no one was if it were truly important to you. On the other hand, people don't expect that anyone is actually doing it. (Note that this trace was taken at a time when your devices were essentially quiet, so the trace shouldn't reveal anything important about your activities. Double-checking as best one can with 175K packets, that seems to be the case. At the same time, I bet at least some of the devices in the trace are yours, which I'm hoping makes taking at least a brief look more enticing.)


Computer Science & Engineering
University of Washington
Box 352350
Seattle, WA  98195-2350
(206) 543-1695 voice, (206) 543-2969 FAX
[comments to zahorjan at cs.washington.edu]