Fig. 1:Wireshark packet capture example. In blue highlight the Web browser performs a ‘GET’ request to a remote server in plain text.

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 marvelous “sniffer.”

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.

Linux 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 one another).

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 stop button.

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 123.1.1.12, 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 yourself.

A typical filter string is of the form, “object==value.” (Note the double equal signs.) For us, the most useful objects are:

ip.addr — 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) port number
tcp.srcport — TCP, source port only
tcp.dstport — TCP, destination port only
udp — UDP (Universal Datagram Protocol) port number
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 perfect example.

HD PAD PROBLEM EXAMPLE

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 DATA

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 rwee@nbmedia.com.