|
|
|
|
Wireshark Exercise
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.
Mechanics
Wireshark
Running Wireshark requires root privileges. On your own machine, that shouldn't be a problem.
For use on attu and the lab Linux workstations, there is a special installation of Wireshar
at /usr/sbin/wireshark that doesn't
require root, but limits you to examining log files (rather than capturing live data from the network).
(Note: Do NOT just issue the command 'wireshark' on CSE machines. That will launch
a version that will fail (on an insufficient privileges problem). Instead, give the full path
name to the correct version, /usr/sbin/wireshark .)
Launch Wireshark from the command line. Select "Open" on the screen that appears to
open the log file.
Log File
It's here.
The Questions
The following questions can be answered from the information in the packet trace file.
- As mentioned earlier, a Fedora 11 machine boots during the time the trace is being taken. What is
the IP address of that machine?
- From what machine does the Fedora machine obtain its IP address? (Identify the machine by giving its IP address.)
- There is a single gateway (to the Internet) on this network. What is its address?
- 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?
- 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.))
- What does the trace tell you about how many Ethernet bridges there are gluing together the local
network?
- OPTIONAL As best you can, guess what kind of thing each physical box is. (Okay, now that's vague. But, it's optional.)
Wireshark Optional Section (Recreational Interest Only)
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 protocol 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.
|