Before we start the next module, there was a question in the forums asking
what happened to the data, I'm sorry, what happened
to the chapter starting a capture
capturing packets timestamps and time values, navigation sample captures.
Apologies but we already went through those. If you've missed those, they would be available
on the website to stream for once this live broadcast is completed,
INE will package up the data.
And it will be available for you. What I will do is very quickly and briefly
before I go into the next, into the next topic is basically to cover those very quickly.
Starting a capture, basically off the lauchpad,
you select your interface, you have capture options.
You start your capture. And from there you collect your data,
you stop the capture and then you can further filter it.
Timestamps and time values - we went through these.
This is probably, this is the first topic we covered today.
And one of the things that we covered with timestamps and time values is that
in your Wireshark capture here as you can see
we have, let's zoom in a little bit. You have your time column.
And what you can adjust is specifics to the view menu time display format.
You can change it to seconds since beginning of capture,
seconds since previous capture packet, and so on and so forth.
What we covered in that module is why that's important.
Essentially, in a nutshell, the gist of it is that if you have from source to destination
you have some kind of performance issue, let's say, there's some kind of latency.
You can capture that in your packet.
So when we use an example with HTTP and the traffic is moving from one place to the other,
if it's taking an abnormal amount of time for the response,
as an example, you will see that as the time delta.
And you can use that as an example of a, against the baseline.
You can also go into your summary and
you can get some information there as well, how many packets.
And so on and so forth. So you can get an understanding of how long your entire
capture was. That will give you some information.
However, if you go packet by packet, it will allow you in milliseconds to
figure out just how long it took for things to happen in a transaction.
So I hope that answers your question.
Otherwise, the rest of it would be up online as soon as the,
they're done packaging the product.
Ok, in our next module, we'll be discussing about advanced filters.
This is the last filtering specific module that we will cover.
However, I will say that through the rest of the
examples that we give and the things that we do
while we're troubleshooting, we will be using filters.
So this is not the last time you will see it. Let's say that from here on out,
it's more than likely you will be building filters quite often while you use Wireshark.
And as you can see, some of the things that we've done is we've
worked through some pretty simple filters
all the way to the more advanced, the more advanced
we will cover here in this module.
But as you can see, a filter again is just to refine the traffic.
It's going to get muddy. You're not going to be able to see what you want to see.
And by doing filtering either pre-capture or post capture,
when you run a display filter, you'll be able to minimize what you need,
minimize the stuff in the capture you don't want to see.
And bring to the surface or highlight the things that you do want to see.
So that you can find root cause of a problem.
So there's, there's a actually a lot of different display filters that you can set up.
Obviously, we've talked about capture filters. I think we'll leave that one for rest for now.
The major difference is it works in the Berkeley format.
It's different than a display.
I'ts used to isolate things off your capture that you don't want to see
such as net bios, off those types of things.
Your display filter is going to be something that you apply afterwards and
there's actually a lot of different types of filtering that you can do.
So, here as you can see on the screen, I've bolded a few, bolded a few of them.
And one of the filters that you can see is a stream filter.
And that will actually show you the entire conversation
either the TCP or UDP.
We'll show that live so you can understand what that's about.
There's macros you can write. There's conversation filters that you can build.
We highlighted that briefly either on another mod,
question and answer period we did.
And as you'll see, as we mentioned in some other
questions and answers, you can do this in an I/O graph.
Pretty much anywhere in Wireshark, and we'll get to each one of those tools
and we'll show you how you can use filtering in them.
But the key concept here is with advanced filtering
is that you start with the most basic. You learn the syntax of it.
You use the, the expression filter to kind of help you build some stuff.
And then once you move more into using the tool,
you could start to, as you see here, start building your own filter types
right in the, in the open window here.
You can basically type in something as long as this,
where it basically says,
that I want the IP address equal to this IP.
And the IP address equal to this IP.
And specific UDP ports such as 53 which will help me to isolate.
You guessed it, right here, DNS traffic.
So, one of the reasons why we did this is we wanted to see, alright well
I have a DNS server here that is not working.
It's, there's some problem here.
My client doesn't seem to be able to resolve DNS.
And why would that be? Well, as we write this filter
and we drill down into this specific traffic to look at
one IP to another to figure out why on UDP port 53,
it's not really working here.
Alright, I have a few clues where I can see that I have a type 3 destination unreachable.
And I have some resource records in here that are not being answered.
So as we can see from our filter that we drew
a more advanced filter that essentially we have a DNS problem.
And that is exactly what the whole point of filtering is.
And this was not even a super complex one, it was just long and maybe difficult to write
and that's what I think makes them more advanced.
But once you understand the concepts of networking
and be able to put your detective hat on and isolate a little bit of the problem
then it's likely that you'll be able to come in,
write your filter, display the traffic that you want to see, or I should say,
the packets you want to see
and start drilling into the details and finding things out
that you need to know and will tell you the story.
The client's trying to clear the DNS server.
It's not working. And now we know why something is broken.
Why is it not resolving?
So that's a way for you to dig deeper into what is going on.
Alright, so back to another capture. Let me just load this up.
And as we see this was a very simple one.
Again, it was very muddy. There's a lot to scroll through here.
One of the things that we wanted to highlight
was that you can pull up your protocol hierarchy.
And another way to do this is to pull up conversations from the statistics menu.
So your statistics menu, I could see here that -
Oh ok, well I have a few things going on and maybe I want to look at the top talkers here.
In bytes or in packets, we will the take most packets.
And maybe I want to see specifically, I'll apply a filter.
And I want to see specifically, what that looks like,
just that traffic.
And as you can see, in the filter, I could have wrote, written that.
I could have said, ethernet or e dot address equals,
usually a double equals,
the MAC address, ---- ---- and the ethernet dot address,
equals, equals the MAC address,
the source to destination conversation and would uphold this filter.
Well, maybe I want to refine this further, Maybe I want to dig in a little bit deeper
into this traffic and I can go into my details pane and I want to follow the UDP stream.
And I can see specifically, there's certain DNS servers that I might be looking for here now
that I might not be, might not have on my network and then I can
ping them and see if they're responding.
So again, this is the, some of the ways that you can use this
Wireshark to drill down more into filters
and find a more detailed information.
You can, of course, just write in here DNS and it will pull the DNS information for you.
Or you can write something a little bit more complex.
So specifically, we've covered capture filters, display filters,
we did a little bit of conversation filters.
Let's go a little bit deeper into streams.
So why is the stream important?
Well, in this, in this conversation we're following a UDP stream.
And here we want to see something very specific.
We want to see if we were resolving something maybe what domain name was it resolving to.
Maybe I could throw that in the web browser and try to see if that resolves for me as well
on the same client or on the machine that's nearby.
You may not be able to see that directly right from the packets
if you're going packet by packet.
You may not know that there's 8 different conversations going on at the same time.
So one of the tricks to doing this is to specifically find a conversation
in your packets list pane. Maybe use a conversations filter and say,
alright well, I know it from this source IP, I run an IP config or an IP config and I say,
on this system, this is the source IP address.
So I know that's what I'm going to start filtering on.
Maybe search for that IP.
And I want to know what DNS server it might be trying to connect to.
And if I at least go to the source and I look and follow the first query
and I pull UDP stream, I might very quickly be able
to find out something such as this.
What was the domain name that they were trying to get to?
Upon further investigation, I can find other things.
I can find other protocols that are involved.
I can also change it from raw data.
I can look at arrays, I can look at pure hex dump.
Or I can pull ASCII data. ASCII data is actually very helpful because
then I can take that data and I can re-import it into
into Wireshark to, to build a conversation.
Those are quite a few things that you can do with these streams.
This is a UDP stream. TCP streams get a little bit more intense.
But just for purposes of this lesson, as you can see,
there's a lot that you can glean from this, this capture filter.
And lastly, to close out the filters topics that we've covered thus far,
a quick reminder, that we're doing this to troubleshoot problems,
to learn what's going on in the network.
To figure out more things about the network.
Things that we would not likely see. Things that we cannot gather without looking at the packets.
Once we'd captured all these packets, what exactly are we looking for?
We put on a detective hat. We run a few pings.
We do a little a, we figure out what our, our enterprise looks like.
What's source to destination? We figure out what we want to filter on.
And then from there, we can granulize the output
and we can some specifics
to drill down and find and isolate the root cause.