Ok, welcome back. We're going to talk about
TCP sequencing and handshake for our next module.
And essentially, the TCP handshake
is one where we've been learning this for a pretty long time -
how TCP works, basics of networking, the most fundamental stuff and
why is this so important to really learn when you're using Wireshark.
Well, predominantly, when you start looking at the communications at the TCP layer,
and seeing SYN, SYN ACK, ACK, FIN, reset,
what does that really mean and why is it important
for when you're looking at Wireshark captures.
Why is that something that you need to address.
Well, when we talk about the basic 3-way handshake,
that would create a connection-oriented communication from a client to a server.
And that will allow the communication to remain until officially closed.
Or it's finished. And by doing so,
if something happens in the middle of the communication, for example,
a packet's dropped or it goes the wrong way in the network,
the sequence numbers help you to rebuild the communication once it arrives.
And all these things work together
to create a connection-oriented or
a dedicated connection where
you know when you send, let's say,
data from one source to a destination,
it's something that you know, will get there and every chance that it could take.
Whereas with UDP, it's the best effort and you will not know
essentially, if it got there and it got there in one piece.
So, at the most fundamental level,
this is why this is critically important.
So, just a quick refresher.
TCP, the transmission control protocol, basically aside from IP,
one of the most important protocols in the TCP/IP sweep.
Reliable, connection-oriented, and it allows for a, error checking -
as we mentioned before, the sequencing of packets
which we'll take a look at in the actual capture.
And it allows an underlying mechanism to have reliable communications for protocols,
such as FTP. We looked at that in an earlier module.
SNTP for email, HTTP for web services and so on.
The user datagram protocol, UDP, it's not connection-oriented.
And it allows for faster connections 'cause a lot less overheads.
So as we mentioned also in an earlier module,
if you're just sending, let's say, a file via TFTP,
you may not necessarily need that overhead,
and it will rely on a less, or a protocol with less overhead which would be UDP.
Alright. So, what do we have to worry about again,
when we have to worry about placement?
We have to consider filters, and in this example,
we will also look at the flow graph.
So in this example, a web server which is trying to close
a connection and essentially, one of the things that we were looking at here,
was, and you could see this directly in the packet,
was that, it was trying to close and acknowledge.
There was a re-transmission, and it tried to close
and acknowledge, and then it was acknowledge that it was closed.
So, when you look at each one of these packets and you drill down into the details pane,
one of the things that you should notice here is
in the highlight section is that it's using TCP.
We learned about ports earlier, and this is essential.
So, we're using port 80 from the destination web server.
The source port is 49943 which is an upper layer,
level number port.
And there's a sequence number and an acknowledgement number.
So, specifically with sequence numbers, you can see here, the first one was 1.
Wireshark uses a relative sequence number and
we got on the next one down, a response
and then it moved to another sequence and acknowledgement number.
So as you can see with this very simple end of a transmission,
these sequence and acknowledgement numbers
allow it to be put back together.
And as you could see in here, is the flags.
So for example, you saw in here was an acknowledgment.
Well, in the detail here, you can see that the acknowledgement bit is set.
Right here. And for example, up here when it was a FIN and an ACK.
The FIN is set. And the ACK is set.
So essentially, what's very important to understand here is that
yes, there was specifically, a handshake.
This was the end of the handshake.
But other things that you can pull out of this information was the roundtrip time
for that specific segment.
And if we wanted to look deeper into it, we can pull up the flow graph.
And take specific look at the time it took
and the sequence numbering and the acknowledgement number.
So why is this important?
Again, when you're looking at large captures, where you see
tons of re-transmissions, tons of duplicate ACK's or other types of TCP errors,
you can take this foundational knowledge of looking at
specifically the handshark itself.
Understanding specifics of the handshake, looking at the sequence numbers,
looking at the flags that are set and other detail
within the Expert, the flow graph and as well as the capture window
to try to estimate what the problem was or could be.
And you can also build out larger TCP filters.
You can do streams. You can look at specific TCP analysis
where if you're looking for specific sequence numbers,
you can drill down and look exactly for, for a specific sequence number.
So if you're looking at a number of captures
and you're really trying to do a deep analysis of where traffic was sourcing from
what the destination was seeing, you can use this simple tools
to pull together the entire conversation.
But again, understanding the basics of the handshake and sequencing
is required for those, those larger captures where
you're trying to really find a needle in the haystack.
But as you can see, you can filter on pretty much anything
within the TCP framework here such as sequence numbers and so on.
So what can Wireshark help you find by doing this type of set up?
You can look and find latency in your network.
Again, just looking at TCP, may not give you the entire picture.
You may want to know from where your source is
to where your destination is.
Run a trace. See if things are taking a long time.
Check your path. Make, make sure - maybe you have a synchronous routing issue.
You might have out-of-order packets, many re-transmissions,
duplicate ACK's, fragmentation, and so on and so forth.
So again, it's very important to take a look at the entire path
from client to destination, from source to destination, client to server.
You're looking for your basic 3-way handshake, your SYN, SYN ACK, ACK.
And then close out, and then any variations of it.
Is it duplicate ACK's?
Are you getting re-transmissions?
Or you're getting constant resets?
And those will give you clues as to why you have an issue.
And to add, as well, we'd have now look at specifically some sequence numbers
and how to find those in the capture themselves
so that you can put the entire conversation back together.