So signing in to Wireshark foundation,
hopefully, we're all able to take a break and get some air.
We're back and we're going to continue with the next 2 modules on filters.
Just a basic primer to catch you up if you're just joining now.
So, why are we filtering traffic? Well, when you run a capture on Wireshark
it can collect a lot of data. And it will likely collect everything
especially if it's in promiscuous mode.
It'll capture everything that it sees on the network.
So, if you're trying to isolate something like a, a slow file download or transfer,
or you're trying to pinpoint why an application is not responding,
you know, in a way where it's acceptable poor performance.
Again, things that we had discussed earlier in the course is
you don't just load up Wireshark and it won't tell you what the problem is.
You know and, and specifically say this is what the issue is.
But it will allow to collect that data and take a look within it and do some protocol
packet or traffic analysis, or network analysis and
allow you to look in and see what's going on.
So, how do we see what's going on is by putting our detective hat on
saying, ok well, this is the client that can or is having the issue
with this server or this destination system and I want to see what's going on between them.
And again, we have this huge amount of data that we've collected
what are we going to do to, to refine it, to really see exactly what's going on,
or we do that with a filter.
And as we mentioned before, the filters will allow you to refine the data
before you collect it so you can do a capture filter.
It will block out things that you don't want to see.
Commonly, if you don't want to see your ARP's or ARP's at all,
net bios traffic, things of that nature.
It won't even collect it and or you collect all data and you run what's called a display filter.
So our next module is called display filters and what a display filter does
is it takes all of the data that you've captured and allows you to apply a filter
to remove things that you don't want to see.
So as we just mentioned, it does so in the packets list pane.
So, when you run Wireshark and when you're capturing, you record your packets.
You have your 3 panes, the topmost, being the packets list pane.
And this is where you will see each and every packet that you've captured.
The display filter, you can run and it will limit what appears in the packet, packets list pane.
You cannot also go into the details pane and set up a display filter
to show you in the packets list pane specific things,
for example, if you wanted to see
some data specifically like an ethernet frame type or something.
And you could find that in the details then right click that detail,
and apply this filter and it will then show in the packets list pane that refined data.
So, there are reasons why you would actually run a filter off the details but
essentially, what we're going to learn in this module
is how to apply a filter to a display.
So again, why do we do this?
It's an aid in your troubleshooting efforts.
When the fire alarm goes off and people want their network fixed
so their application running smoothly, they call on us,
the network engineers and analysts to help save the day.
The last thing that I personally want to do is set up Wireshark in the wrong spot,
collect data for 3 hours and crash my machine
because I have so much data that I don't know what to do with it.
I'd rather know strategically where I'm going to put it.
Capture, hopefully capture what it is that I'm looking for.
And then further refine it down to what it is that I may think the problem could be.
So again as we discussed these 2 filter types, this capture and display -
your capture filters applied prior to running a capture,
it will block out some stuff that you don't want to see.
Display is run afterwards.
And when you do run your display filter
there's a lot of things that you can do here.
However, we will run a sample here for you to see.
So, particularly here, I've ran a capture and I've captured some HTTP traffic.
And I want to further filter on it. So, one of the things that you could do is
you could essentially say, alright well, I know that the client was looking,
looking up this website prior to going to it.
Maybe I missed it but I do see some information here that may be relevant to that.
What I could do is I can go to statistics and I can look at the protocol hierarchy.
And this will tell me exactly what protocols are listed or found in the capture.
Very helpful for writing a filter because instead of
you know, scrolling down, yes if you only have a few hundred packets,
it may not be a big deal but navigating through a capture with a thousand plus packets,
it may be quicker and easier to just pull up
your protocol hierarchy and say, ok well, I know I have IPV 4.
Obviously Ihave some ethernet here.
It's using TCP drilling up the OSI, going up the OSI model.
It's using HTTP, hyper text transfer protocol.
It gives me percentages of use obviously.
And I can see here that some, there's some UDP query traffic,
primarily using the domain name service. Very good to know.
So what I will then do is I will then, and again, I can go into my expression
and right here, I can drill down and
search for DNS if I need to look for DNS.
And select what it is that I need to see or
in this friendly filter toolbar, I can type DNS.
And it will show me exactly what the DNS packets are doing.
It'll, It'll filter for them and then I can drill down into them and say
ok well, UDP port 53 is likely a query, yes it is.
And the, it was a request. So as you can see here
specifically, it's very helpful to know how to filter in for your data because
it will help you to figure out things. So for example,
in this particular problem, whomever was raising the complaint said -
Oh, you know, I was trying to hit the website, it was very slow to come up.
Or what exactly does that mean?
Well, now I can look and drill down into the specific HTTP data.
And I can also look at the DNS queries and see
how that, how it was responding.
Also, on my filter toolbar, I can also clear out the,
what's in here in the filter.
Obviously, I can just erase it or I can hit the clear button.
But just a quick tip, something very helpful. If you could see here,
I have a couple of them already saved up.
I have a TCP full handshake conversation and I have one for ARP.
You can click the save button and it will allow you to save this filter
on your toolbar. Obviously, you want to name it but
if you then want to clear out and then quickly run a filter on DNS.
as an example, you can just click that quick short cut button and you'll be off and running.
So as we mentioned before, it can get complex but
for, for all intensive purposes here,
we want to just make sure that it's understood that
running display filter is primarily used to
remove unwanted data, help you drill down into what it is that you want to see
and remove a lot of waste that you'll capture so you can streamline your viewable traffic.
to see what exactly you want to see.
Remove whatever it is that you don't want to see.
And allow you to have a clearer picture
as to what it is that you're going to be working on
analyzing or troubleshooting.