When Wireshark Gets Confused...

Note:
SIP/VoIP call setup is covered in Chapter 27 of Wireshark Network Analysis.]

I was scrambling around in preparation for a VoIP training session recently
when I opened a new VoIP trace file that depicted a simple call set up routine
followed by the actual call.

Strangely, Wireshark had an issue identifying one side of the SIP connection -
as you can see in the graphic above. Wireshark dissected one-half of the
conversation as FF (Foundation Fieldbus) traffic.

What in the world is going on here?

Wireshark defines the protocol column value based on the highest layer of
decode that it can apply to the packet. In this case, Wireshark found something
in these packets to indicate the traffic was Foundation Fieldbus packets.

I compared the packets defined as "FF" to the packets correctly interpreted as
SIP.

Aha! The port number fields tell the story. In the UDP header, packets that
contained the source port of 1089 are dissected as Foundation Fieldbus. Ok -
let's just skip past the fact that the sender in Frame 2 above is not responding
to the correct port number defined in Frame 1.

My focus was on getting Wireshark to dissect the packets marked Foundation
Fieldbus as SIP packets. I certainly don't want to alter the preferences of
Wireshark so that all packets containing source port 1089 are dissected as SIP
packets (as they likely are just ephemeral ports and not SIP at all).

The quick solution is to right click on the packets dissected as Foundation
Fieldbus and select Decode As. Selecting SIP as the desired dissection and
applying this to the trace file fixed the problem quickly. Wireshark now
dissected source port 1089 as SIP. Clicking the "Show Current" button in the
Decode As window displays all manually altered dissection configurations.

It's not often that I have to apply Wireshark's Decode As function - typically I hit
companies using non-standard port numbers for applications for various
understandable and just plain whacky reasons).

It's a great feature to know - just in case you hit a strange dissection.

Enjoy life... in the Netherlands... one bit at a time!

Laura

Europe Welcomes Wireshark University

On May 31st, the first Wireshark University course opens in the Netherlands!
The Core 1 course registration is now open with our first European partner,
SCOS. For information, visit www.wiresharkuniversity.nl.

You do not want to miss this event!

This course teaches you how to capture wired and wireless traffic and interpret
the most common TCP/IP communications including IP, ICMP, UDP, TCP,
DNS, ARP, DHCP, HTTP and email traffic.

Register online today at http://www.wiresharkuniversity.eu/trainingdates.htm.
For more information, email info@scos.nl.

In addition, SCOS is a European distributor of the new Wireshark Network
Analysis book (www.wiresharkbook.nl). There should be copies of the book
available at the training to help you prepare for the upcoming Wireshark
Certified Network Analyst Exam (due Q2/2010). For more information on the
Exam, visit Wireshark University.

Betty DuBois, Lead Wireshark University Instructor, will be presenting this 5-day
event focusing on the key capabilities of Wireshark, the world's most popular
network analyzer, and TCP/IP communications analysis.

Special thanks to Matt Hamburg of SCOS for hosting this very special event.

Enjoy life... in the Netherlands... one bit at a time!

Laura

Baseline Today!

In one of the early book reviews, Marcos Christodonte II states “I’m a firm
believer in baselining network traffic. In this section, Wireshark Network
Analysis details the importance of baselining and the types of traffic to focus on.
Like other sections, this section also provides screenshots, showing how to
analyze traffic and packet statistics.” [Read the full review here.]

Every IT professional should take baselining seriously. It’s not difficult to do and
will save you time, money, frustration and possibly your job when all hell breaks
loose on the network.

Baselines define your network’s vital signs when it is healthy. Baselines are
used to define not only the basic traffic flows of an application or process – they
also help define the number of connections required by a process, the type of
connection, the port numbers, interdependencies with other hosts, typical round
trip times, average packet per second rates, average load time and more.

Chapter 28 includes my baseline checklists - listing the traffic you should be
capturing and what you should be looking for when characterizing "normal"
behavior.

For example, if you want to create a baseline of your login/logout sequences,
consider the following questions:

• What discovery process takes place during login?
  
• What server does the client connect to?
  
• What are the processes seen during login?
  
• How many packets does a typical login require?
  
• Are there any login dependencies?
  

When someone complains about a slow login process, compare the current
ugly login to the baseline you created.

• Are there any large gaps in time?
  
• Are there any Expert Info notifications?
  
• Do you see the same number of conversations as in your baseline?
  
• Do you see the same number of endpoints as in your baseline?
  
• Do you see the same protocols as in your baseline?
  
• Do you see the same number of packets as in your baseline?
  
• Do you see the same dependencies as in your baseline?
  
• Did the name resolutions process match your baseline?
  

You don't have to know everything about every packet and protocol in use. Use
the ugly trace and the baseline trace to identify large gaps in time, large
differences in packets, unusual error responses. All of this enables you to point
the finger at the problem.

Remember - in a finger-pointing world, the only finger
that counts is the network analyst's finger!

So… schedule some time to create your baselines now – before you need
them.

Enjoy life... one bit at a time!

Laura

HELP! I've Been Tooned

If you went to BrainShare 2010 and watched the Monday or Thursday keynotes,
they were preceded by two short behind-the-scenes videos. In each video a
domineering packet geekess prepares systems for the show while "Fred"
(likely the user from hell) sweats it out through last-minute stress.

Yup - the geekess was my voice and a toon of me (although my boobs are
smaller as I told the project coordinator, Russ Dastrup, after seeing the initial
animation images).

• Monday BrainShare keynote video
  
• Thursday BrainShare keynote video
  

Russ asked me to prepare a script of some of the geeky things that I might say
- if you're an old-timer, you might have caught the reference to Compsurf
(remember those good old days?). There was also a reference to Wireshark in
there.

Chris Miller supplied the voice talent for Geeko and Fred - from what I heard at
the recording studio, Chris is a pretty famous voice talent (Geppetto in Shrek is
listed as one of his credits - cool!). Those voices were recorded before mine. I
meandered into Soundtek Studios here in Campbell, California for my voice-
overs. When I walked in I was spending more time looking at their recording
equipment (they are a Mac shop) than the instruments (although I did consider
playing a little tambourine).

It was ironic when they had network problems (an unplugged Ethernet cable)
before we started. The technician, Pat, was speaking another language most of
the time - "too hot" "too out there" "more eeeee". At one point he told me to be
"less orgasmic" when I was trying to add some energy to my voice (I'd been up
almost all night working book edits and I was in dire need of a triple espresso).

At the keynote a few people said "Hey! That's Laura!" and they were right. Ya just
never know where I'll show up.

Enjoy life... one bit at a time!

Laura