All Tooled Up – Wireshark

Wireshark is a packet analysis tool. It reads and displays the data packets going in and out of your NIC. You can download it from here.

For those of you who think packet analysis is only network administrators, think again. Packet analysis is one of the most powerful troubleshooting tools to have at your disposal. It can be used to troubleshoot all manner of application and configuration errors.

Here’s a list of all the things I wished I know before I started using it.

TCP Communication

When I started using Wireshark I didn’t my SYN – SYN ACK – ACK from my FIN – FIN ACK – FIN – FIN ACK; it didn’t end well. If you think a TCP 3 way handshake is an antiseptic greeting between a trio of friends, then you need to read up on the basics of TCP communication before going any further.

Personally I find most comms documentation and forums quite difficult to read. They all seem to be written on a 1980’s processor with an RFC aesthetic. However, saving the day, is Laura Chappell’s excellent book  Wireshark Network Analysis, it is a great resource for anyone starting out with Wireshark.

Placement of Capture

In an ideal world you would have a great understanding of the faulting system and have packet analysers set up at strategic points, tracking the flow of data. However in practice I’ve found it difficult to convince network and system administrators to let me install packet sniffers on their infrastructure.

Consequently a lot of my captures are from end devices, where users don’t seem to mind you installing capture software. Don’t worry if you can only get captures from the end device, you’ll be amazed what they reveal.

Careful What You Capture

Just like ProcMon Wireshark produces masses of data. The idea when using these tools is to capture for as short a time as possible. Try to capture the seconds around the performance issue or error.

Look at the right layer

Although I passed my Network A+ exam many years ago, I never really understood the significance of the OSI model.  Put simply, each layer is reliant on the layer below to function. Most network troubleshooting takes place from the TCP down; this is where the comms guys really earn their crust.

When you use Wireshark to troubleshoot non networking issues you need to concentrate on
TCP upwards. The majority of clues are found in the TCP connection or the control commands the application layer sends.

Don’t Cross the Streams

TCP streams as one of the basic building blocks of a packet trace, especially when looking at performance issues. Fortunately in Wireshark the “Follow TCP Stream” option is only a right click away. Long pauses within streams indicate an issue. With multiple streams taking place at any given time they can be difficult to spot unless you isolate individual streams.

A complementary method is colourising  the TCP streams. This allows you to see how the streams interact. If you only have a single stream running at any given time or there are long pauses after streams finish, then that’s probably where your problem is.


Although this is definitely not a how to guide I want to touch on filtering because it took me a while to get to grips with it, and much like ProcMon filtering is at the root of good analysis.

Just to make things simple there are two sorts of filtering, capture and display, each with a different syntax. Although purists will tell me I shouldn’t, I always use the No Broadcast and no Multicast capture filter as it takes away a lot of the noise.

The single most useful filter for me cannot be created from a right click and seems weirdly under-documented. To display all the packets with a given IP (for instance as the source or destination use

ip.addr ==

Also if you want to filter on a given protocol just type the name of the protocol into the filter bar. Be aware that it will display all packets that sit on that protocol. So typing in TCP will display HTTP and SMB packets because those two protocols rely on TCP connections.

Delta Time

Delta time is a useful column to add. It calculates the time since the last packet. Sort on delta time and look for similar length pauses. Multiple pauses of a similar length would indicate a timeout of some description in your system.

Remember there will be a lot of SYN’s with high delta times. These probably just indicate natural pauses in activity.

Well so much for the basics. The next post will be putting some light packet analysis into action.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s