Beginner's Guide to Wireshark - Part 3 (The TCP Handshake)

Last Time...

Parts 1 and 2 of this article can be found here:

Beginner's Guide to Wireshark - Part 1

Beginner's Guide to Wireshark - Part 2

In them, I went over the process for install Wireshark and WinPcap on a Windows computer. Then I looked at starting up Wireshark for the first time, selecting an interface and doing a simple packet capture.

This third and final part expands on the previous two parts and introduces filters.

Note: Click the screenshots to view larger versions



IP Header

Previously, we looked at the TCP header. Now let's turn our attention to the IP header and what it contains.

A few more interesting values are shown here. Besides the source and destination IP address being visible, we can see that the version of IP used is 4 and that the header length is 20 bytes. In addition, there's even a field that defines which protocol the IP header is encapsulating - in our case, TCP. All useful information that could potentially be used for constructing filters. Although I touch on this later, I recommend you follow the links at the end of the article for more information on this.


Now that we've gone over a basic capture and how to view all the information contained within individual packets, let's look at how we can filter the packets. We'll stick with our Google capture for the time being. Say we only want to view the packets that originate from Google and NOT the ones that originate from our local machine. How can we do that?

Simple.

As you can see, I've entered a capture filter in the box above where the packets are listed:

ip.src == 141.30.3.84

It's fairly self-explanatory and effectively just tells Wireshark to display all packets that have a source IP address of 141.30.3.84. After pressing Enter, the list of captured packets instantly changes to show only the packets we want to see. Clearly, the use of filters could be extremely useful. If you're running Wireshark on a big corporate network and are seeing thousands of packets fly past each second, you can't possibly pick out the ones you want - particularly not in a live capture. But by using a filter, it's easy.

You can filter based on a huge number of things: source, destination, protocol, port, subnet, flags and much, much more.

This website provides more information on how to construct these filters. Clicking the Expression button next to the filter box can also help you construct them, although it won't be discussed in this particular article.



The TCP Handshake

This section was deemed appropriate as it could prove useful for people new to Wireshark. All users of Wireshark should be able to identify a TCP handshake. In the past, I've needed to determine whether a TCP handshake is taking place or whether something - be it suspicious routing, a misconfigured firewall or a faulty network card - is preventing it. So how can we check?

Take a look at the next screenshot. I've begun a new live capture and established a new connection to Google. Since a TCP handshake takes place at the very beginning of any TCP connection, we want to concentrate on the first few packets.

Let's have a look at those first few packets, one by one.

1. Clearly a DNS query, my computer (10.0.2.15) asking the DNS server (208.67.222.222) to resolve www.google.co.uk.
2. The reply from the DNS server, complete with the IP address for Google (173.194.37.104).
3. The first packet making up the TCP handshake. The SYN packet my computer sends to Google.
4. Google sends back a SYN ACK packet (that is, a packet with the SYN and ACK flags set - expand the TCP header as we did before to examine it in greater detail)
5. Finally, my computer completes the handshake by sending back an ACK. My computer and Google's server are satisfied that the connection is established and the transfer of data commences.

So there we have it, a good example of a 3-way handshake. If you're not already familiar with the workings of TCP, its flags and so on, a bit of practice identifying them and working out what the packet does will soon become a lot easier. As with all things, practice is the key!


What's Next?

So what's next? Well, that's for you to decide. In this article, I've barely even scratched the surface of what Wireshark can do. It has been to give you an idea of how Wireshark operates and what it's capable of. The best way of learning something new is to strike out on your own, experiment and read all you can about it. Here are a few ideas to take things further, however:

* Fire up Wireshark while sending email using a client such as Microsoft Outlook or Thunderbird. What can you see? Which protocols are they using? Are you able to read any of the messages?

* What can you see when making an encrypted connection? What happens when you use SSH?

* Run Wireshark and ping something. Ping doesn't use TCP or UDP, so what do you see?

* If you come across any strange packets (and believe me, there are lots of strange packets flying around out there), investigate them. What are they? What protocol are they using? What kind of device may have sent it?


If there's enough interest in this article, I may write another, exploring more of what Wireshark can do. Comments and suggestions are very welcome.


Beginner's Guide to Wireshark - Part 1

Beginner's Guide to Wireshark - Part 2



Comments 2 comments

jeff 5 years ago

I'd definitely read a follow up article if you wrote one - this was perfect introduction and wireshark is my new favorite toy -

thanks a ton - i appreciate your work!


AMSpace profile image

AMSpace 5 years ago from London, UK Author

Hi jeff - thanks for the kind words! Glad you found it useful; I certainly intend to write more about Wireshark in future.

    Sign in or sign up and post using a HubPages Network account.

    0 of 8192 characters used
    Post Comment

    No HTML is allowed in comments, but URLs will be hyperlinked. Comments are not for promoting your articles or other sites.


    Click to Rate This Article
    working