Fig. 1:Wireshark packet capture example. In blue
highlight the Web browser performs a ‘GET’ request to a remote server in plain
In previous articles,
I’ve used the Wireshark network protocol analyzer to create various
illustrations. Given that this is one of the most powerful tools ever created
for network troubleshooting, it’s past time that I devoted an article to this
The usual disclaimer is on a lighted billboard this time:
There is absolutely no way that I can cover even a tiny fraction of Wireshark’s
features in a single article. I will have to oversimplify some things.
My examples were done
using Transmission Control Protocol over Internet Protocol (TCP/IP) atop
Ethernet; while it’s by far the most common, it’s not the only way. Wireshark’s
Website (www.wireshark.org) and Wikipedia
(en.wikipedia.org) are your friends and will cover things that I had to
omit. Read the documentation!
PROTOCOLS AND PACKETS
A quick refresher is in order before we get
started. All network data is sent in packets — short, manageable chunks of
data. A large file is split up, sent in separate packets, then reassembled at
the other end. Each packet is wrapped with headers containing information on
the source and destination addresses and the length of the data. Wireshark lets
you examine each of these layers down to the byte level.
Fig. 2:To begin capturing packets, select the local
Ethernet interface on your computer and hit ‘Start.’
A communications protocol is simply a
way to format data so that both sides of the conversation can understand it. A
higher-level protocol can “ride” atop a lower-level protocol, with each
protocol optimized for a specific purpose. The Ethernet protocol “talks” from
one MAC address to another. Go up a layer and you’ll find the Internet Protocol
(IP) “talking” between IP addresses. Riding on top of that might be other
protocols, such as HTTP for Web pages and POP for email.
Wireshark understands all common
protocols and will display them in a meaningful way. A typical packet capture
will allow you dig all the way down into each protocol layer. In Fig. 1, I’ve
captured part of a typical Web browsing session. In the top window, you see
individual packets. Click on one and the middle window displays the various
protocol layers in the packet. Click the “+” marks to see the details for that
particular protocol layer, which will be displayed in the bottom window. The byte
data is to the left in hexadecimal, with the ASCII equivalent (if applicable)
shown to the right.
As you can see in Fig. 1, the HTTP protocol uses
plain text commands. In the highlighted example, my Web browser has issued a
GET request. It’s telling the remote Web server what it wants next. It includes
my Web browser (Mozilla Firefox), the desired language (“en,” or English) and
other information. The server uses this to craft and return a page that
satisfies my request.
IT’S EASY TO BEGIN
Download Wireshark from www.wireshark.org and install
it. When you run it for the first time, don’t let all the buttons and menu
options scare you off. You won’t need most of them. It’s actually easy to start
using it right away.
Wireshark provides many different ways
to capture data from your network (read the documentation). But I want to get
you up and running, so just click the “Capture” item on the menu, then click
“Interfaces.” This will bring up a list of all network interfaces on your
computer. You must select one from which to capture.
uses standard names for all interfaces, such as “eth0” for the first (primary)
network card. That’s what I’ve chosen in Fig. 2. Other operating systems
(notably, Windows) use a different nomenclature, but in most cases, you should
be able to determine from the IP address which one you want. You won’t hurt
anything if you click the wrong one, so you can try them all (don’t be
surprised if the “localhost” selection fills the screen instantly; that’s an
internal virtual network that different programs on your PC use to talk with
Fig. 3:Program-Associated Data can be seen in the
highlighted box in the lower right hand corner.
Once you select your interface, click “Start.” Wireshark will
begin “sniffing” the network and capturing a snapshot of everything passing
through that interface. When you’re ready to analyze the data, click on the
A warning if you’ve never done a capture on a busy computer:
You will be flabbergasted at the amount of information that flows through your
network card. The top window may fill with packets in an instant, making it
very difficult to find what you’re looking for. We’ll address that next.
Go ahead and do some captures to see
what happens. You can even amuse yourself. A typical small Windows peer-to-peer
network engages in a constant George Carlin routine. Each PC yells, “Who’s
dere?” followed by, “I’m dere,” and “I’m dere, too.” “OK, everybody’s dere.”
This repeats over and over, round the clock.
HOW TO FILTER THE ONSLAUGHT
Go back to Fig 1. Near the top, under the menu bar,
there’s a text box labeled “Filter,” with a button to the right called
“Expression.” This is one of Wireshark’s most powerful features. Once you learn
how to use it, you can tell Wireshark specifics such as, “only show me packets
to IP address 126.96.36.199, for port 1300, which use the XYZ protocol.”
Click the “Expression” button to get an idea of just how many
different filter options Wireshark offers. Learning all of them requires that
you delve into the documentation — and speaking from experience, it takes
practice and patience to get a really complex filter worded correctly. But here
are some quick-and-dirty filter strings to get you rolling. Print this out and
use it as a cheat sheet. You can just type these directly into the “Filter” box
A typical filter string is of the form, “object==value.”
(Note the double equal signs.) For us, the most useful objects are:
IP address, source or destination
ip.src — IP address, source (your computer)
ip.dst — IP address, destination (the other computer)
tcp — TCP (Transmission Control Protocol)
tcp.srcport — TCP, source port only
tcp.dstport — TCP, destination port only
udp — UDP (Universal Datagram Protocol)
udp.srcport — UDP source port only
udp.dstport — UDP destination port only
You can combine strings with “and”. For example,
suppose my printer is at IP address 192.168.1.12, and receives data on the
standard JetDirect port number, 9100. The filter string “tcp.dstport==9100 and
ip.addr==192.168.1.12” will let me examine all packets sent to the printer.
There are ways to set up filtering before
the capture (useful if you’re on a really busy computer), to save and restore
files filled with capture data, and more. But what I showed you above just by
itself will prove absolutely invaluable right off the bat. Let me close with a
HD PAD PROBLEM
Let’s say you’re unable to get
Program-Associated Data to display on an HD receiver and you’re not sure where
to look. I’ll assume you’ve checked the cables and other obvious things, that
you can ping both the PAD source (typically the server for your audio
automation system) and the receiving end (typically your HD exciter/generator).
Everything looks OK, but the PAD just won’t work.
My audio server is at 100.100.150.204 and the HD
exciter is at 100.100.150.233. The exciter receives PAD via UDP on port 1000
(if this information isn’t in the manual for your HD equipment, call customer
support and ask).
Install Wireshark on the audio server,
i.e. the “sending” end. Don’t worry, I’ve never run across a case where
Wireshark affected the proper operation of the system. We have it installed on
our audio servers. In fact, customer support has used our Wireshark captures to
help troubleshoot problems themselves.
In Wireshark click “Capture,” then
“Interfaces,” and select the network card that sends data to your HD
transmitter. Click “Start” and let it run long enough for some PAD to be sent
(on a music station, a couple of songs should do it). Use the filter string,
“udp.dstport==10000 and ip.addr==100.100.150.233”to eliminate unwanted packets
and show just the PAD data.
An example of what you might see is in
Fig. 3. The audio server for our two talk stations, 101.1 FM and 1260 AM, is
sending a stock PAD string for display on the listener’s receivers. For the
curious, PAD uses the ID3 tagging standard, the same that is embedded in MP3s.
Wikipedia has a good article on it so I won’t go into it here, but you can see
some of the data string as it will appear on the receiver.
Note that Wireshark calls the destination port
“ndmp (10000).”If it doesn’t understand
the protocol (and it doesn’t in this case), it will make its best guess. That’s
why you have the bottom window. You can always look at the raw data yourself.
If you don’t see anything, your audio
server may not be sending the data at all. A good test might be to edit the
filter string by removing the “tcp.dstport==10000” portion. If the data
appears, your audio server is sending the data to the wrong port. Next, restore
the port number and remove the “ip.addr” string. If data appears, you’re
sending the PAD to the wrong IP address.
This kind of troubleshooting is
especially useful with UDP data, because UDP is a “connectionless” protocol.
TCP establishes a connection, and as you’ll see from any capture of TCP data,
there’s constant handshaking: “did you get the data (the SYN and ACK packets)?”
But UDP just throws packets at the target and hopes they will stick. If the
receiving end gets it, all is good. If not, UDP doesn’t care.
With this in mind, let’s assume that
Wireshark shows that your audio server is sending valid data. We need to
troubleshoot the other end. There are plenty of ways to do this, but one of my
favorites is to use a laptop to pretend to be the receiving end.
In this case, you’d disconnect the HD
exciter and plug in your laptop. Set the laptop to the HD exciter’s IP address
and run Wireshark on it (Super Tip: you may need to open the target port in the
laptop’s firewall). If your audio server is sending the data all the way to the
transmitter site, you will see it. If so, troubleshoot the HD exciter. If you
don’t see the data, something’s wrong between the studios and the transmitter
site. Check your link, whether it’s microwave data, DSL or whatever.
WORKS ON ANY
Here’s the best part: This approach will
help you to troubleshoot any network data communication in your facility,
whether it’s RDS data to a transmitter site, song/title info to a streaming
computer … you name it. I’ve only scratched the surface, but I hope I’ve given
you enough to start playing with Wireshark. I assure you, once you start using
this thing, you’ll be sold on it. Have fun!
Stephen M. Poole, CBRE-AMD, CBNT, is
market chief engineer at Crawford Broadcasting in Birmingham, Ala.
Comment on this or any other story to firstname.lastname@example.org.