Good morning and welcome back to the Wireshark Foundation class.
In this module, we will talk about Timestamps and Time Values.
Before we begin, just a quick reminder from what we learned about yesterday.
When we use Wireshark, one of the key things we're using Wireshark to do
is to analyze captured data, data that we capture specifically from
strategic points of the network, so that we can analyze, assess it,
or view what's captured and try to figure out isolation down to the cause of the problem.
One of the key things that we can do when doing this is to do a
a relative time and review the value of time from
when you, let's say, open a web browser to a site
or an application or you're FTPing some traffic
or you're trying to figure out why DNS queries might be slow.
Any of these things can be captured with Wireshark
and when you do that, you're able to look at
for example, how long it took for something to get from the source to a destination.
So in this module, what we will do is we'll learn about how you can
strategically change things within Wireshark.
Take a look at settings and figure out
how long it takes for something to get from a source to a destination.
So essentially, what is a timestamp?
When you open up Wireshark and you begin a capture
each packet is marked with time that you're capturing at.
This is not a time that's kept within Wireshark.
It's actually using your system's time to make that timestamps.
So what's important to understand is that
if the time is off on your computer, for example,
you're capture data is not going to be accurate.
So one of the things that you probably would like to do
is check and make sure that the time on your system is correct.
And one of the best ways to do this is to use NTP
and configure your system with a, a solid time source.
And when you do that, you will at least know that
what Wireshark is capturing and timestamping is accurate.
That being said, timestamps are used to
mark the capturing of your packets,
and you can convert to different time formats
which we'll do in this module.
We'll take a look at the difference between certain settings,
that you could change and why you would use one over the other, as an example.
So why are we actually doing this?
You are able to see the delta between time packet capture.
So if you, let's say, were to open up a web browser
and try to access a website, you can see from when you start
to when you finish and every activity in between,
how long it takes to do certain things. A good example would be
if you were accessing website and you were seeing "get requests",
or you were doing posts and you were seeing long period of time
to complete a function. So what does that actually mean?
That means that as we learn yesterday in the other modules,
you could potentially be facing quite a few different things.
You can have latency on your network.
There could be IO problems on the web server.
The client could have lack of memory to be able to handle the requests.
There's so many different things that can be
a problem within that, that source to destination roundtrip time
and cause contention and or problems all the way from the client to the servers.
So just remember that, you put on your detective hat
and you have to look at all the things in between
as well as the client and the server.
You want to make sure that you consider that the server could be
in tier, that could be multiple layers to that server
especially with today's web server technology.
Usually it's a front-end web server. It's N-tier technology.
This is generally 2-3 tiers.
Sometimes it's split out into a middle ware tier
where you have application specific functions taking place.
And most websites, if they're complex enough and they're taking orders,
or storing information have a database tier,
and that could also be what's hanging things up.
So just remember, it's not just the simple, it can get into the complex.
So when you open up Wireshark,
and we'll take a look at this now.
You can see, you can adjust the time display format.
We're going to get into what each of these values means.
But you can display format. You can adjust it to seconds since time being in the capture,
seconds since previous capture packet,
seconds since previous displayed packets.
And each one of those things is going to show something different.
So as an example, we'll open up Wireshark and we'll take a look.
One of the things that we did here was we did a simple capture and
what I decided to do here, is I just ran a basic capture.
I accessed the website and then I wanted to see the differences
between from my client to this destination.
Basic time values here where how long it took me to do a simple request of a webpage.
So as we were talking about before there's different ways that you can adjust this.
And if you go into the view times display format
it originally was seconds since time and then I wanted to change it
to seconds since previous capture packet.
Now what this allows me to do is to look at each one of these.
I also looked at the stream but I wanted to see specifically
how long it was in between each function here in the capture.
So essentially, that's one of things that we want to do when we're capturing data.
We want to make sure that we are adjusting time to how we want to see it.
And what does that really mean?
So absolute time, the time of day when the packet is captured.
Essentially, one of the things that we want to do is we want to make sure that
we picked the correct function and we want to pick the correct value
for what it is that we want to see. And they're pretty self-explanatory.
So, if I want to see something since the, the previous capture packet
it's going to look at the timestamp from the packet
and then the very next one after that and show me the difference or the delta.
And essentially, if I'm looking at each packet and each packet is performing a function
that will tell how long it took to do each one of these functions.
There's different ways that we can do this.
There's automatic setting or we can change into specific settings
With specific settings, we just want to make sure that
we understand what we want to look for.
And we can adjust those as we see fit.
So let's go back to our capture.
In here, we'll do a simple
capture, start and what we want to do is we want to go to our website.
I'm going to show you a different tool here, too so you can look at
a couple of different things here that we will go to.
When we pull up the website as we can see, there's a couple of different things going on here.
These are a lot of get requests.
And then we're going to stop our capture. And then we're going to look at
specifically what we just did. So in here, we want to adjust
the time display format to previously displayed.
And we can see from each function
how long it took to do each action on pulling a website.
So, one of the things that we want to remember is when we're doing these types of captures -
What are we looking for? Are we going to check the delta?
When you need to find latency in your network, you would use this type of timestamping.
You can check for application response time. That's what we just did. We wanted it.
Look at the website and see how fast they responded to our requests.
We want to see if there's any errors in there, like 400 errors.
To do this, we may want to put Wireshark on both sides of the capture.
This is a very simple capture but if we were doing something where
we were looking at N-tier, we wanted to see response
on the database from the web tier.
We may want to put a capture in between that.
Otherwise, we will not see specifically the latency from one tier to the other.
And we might have to filter the data on both hosts as we just did.
We want to just see the HTTP traffic so we can limit what we see in the capture
and not cause any confusion.
And essentially, we're going to do this type of filtering just to see
specifically how long it took to travel from source to destination
in milliseconds. We can refine that but
essentially we want to see from source to destination
how long it took to pull up a webpage.
And how, how quickly it responded.
Question about time when you capture it is generally in milliseconds.
There are, you can bring it down to nanoseconds.
One of the common things is not all capture files will be able to show this format.
So when you're capturing a data and you're sending it
from place to place and you're sharing it,
if somebody opens it up in a different type of packet analyzer they may not
be able to specifically read everything that you are sending them.
So just be aware of that. Another concern is time zones.
If it does, consider time zones, so if you're sending it around
it will be something that they can read.
Just be aware that if you're capturing something in a different time zone
to make sure that you understand that it is from a different time zone.
So that you can re-adjust it manually for yourself
when you're troubleshooting with it.
Ok, I was looking in the chat forum and there was a
couple of questions that were asked, let me just review.
Ok, so back with the timestamps.
So the question was - you know, when you're, when you're doing this stuff
can you troubleshoot the entire transaction?
Yes, when we get more into the flowgraph, we can see the TCP handshake
and how all that stuff works and we'll be able to look at the timing in between that.
Just as a general rule of thumb, if you pull up your Wireshark capture
and you look at it as we did before, you can see in the left-hand side here
of the window, the time column.
And you could see as you're doing each piece of the transaction, here's a get.
So, obviously, it's doing a request and you can see
when it goes through and post
so you can check to see how long it's taking.
And, generally, anything, you know, over let's say,
forty or fifty milliseconds to post something is probably
not very good depending on your connection. That was also another consideration.
So one of the other tools that we were looking at before we, we closed out this session was
And I'll pull this up now...
was other tools that you can use to validate
specifically, what is being done and what pages are being done?
So, there's tools out there that will allow you
to, you know, pull down the entire cascading style sheet.
There's things that will allow you to accelerate your, your service
so you're not pulling down a ton of little packets.
There's things that can be done to accelerate this,
to reduce the amount of gets.
So, there's things that can be done to increase the performance here.
But just in Wireshark, the realm of wireshark
if you want to look at the actual data and check out and see what's happening here
you can validate from one step to the next exactly how long it's taking with timestamps.
So, it's important to understand timestamps.
It's something that will help you when you're troubleshooting because
as an example, let's say, you're looking at a transaction from a client to a server.
One of the things that you could do is
run a Wireshark capture at the client, like we did here.
If you have access, you can run one at the server
and you can do a compare.
And take a look to see exactly what's going on within a specific set of time
so that you can see where the hang up might be
or where the performance hit may be.
We were talking again about that performance hit.
One of the key things that we were discussing
and we were talking about, one of this I posted in the forum, was that
IO is a big thing. So if you're, let's say, you have a disc drive on the local server
wherein the read-write times are poor
that will potentially show as slow performance when you're accessing a website
if it's, if the system doesn't have enough memory.
If the NIC card is having an issue, let's say, it's not on a gig
and it's on a fast ethernet and you see a lot of problems
where it's actually buffering that traffic.
There's a lot of things that you would look at to see
specifically if you had a performance issue outside.
But this in Wireshark, this example is one of those things
where you may be able to get an understanding of where you need to look.
So as we had mentioned before, if you see long periods of time
or you see tons of get requests, it might be something where
it's just not able to provide you the paging time or it's sending way too much traffic
and you're not getting it back in time.
So, those are some of the things that you can check.
Not only capturing it in Wireshark and giving you clues to where to look
but specifically, do you have a problem with a client?
Do you have a problem on the server?
You know, do you have problem in between on the network?