let's find out what's running on our network, what we're capturing.
So that we can then further drill down into it.
If we're not seeing, for example, SNMP as you do not see in this particular statistics.
Capture - you may not want to start worrying about how to build filters for it
because it's likely that it's not there in the capture to search for.
So, hopefully that through this module, these tools and learning about them
has made it easier and more efficient for you to use Wireshark.
Alright, so one of the questions in the chat are
do we have scenarios of issues to go through and how we use Wireshark
to come to the conclusion of a problem?
So, if you look at the syllabus, tomorrow is pretty much all that.
We're going to go through voice, HTTP,
FTP, wireless, each module is a problem.
And we'll look at Wireshark and figure out how to solve that problem.
So yes, today I'm prepping that in as we talk about the tools themselves.
So as an example, we did bring up a DNS issue where the client could not communicate.
It was in a large capture full of data.
So we filtered out all the data that we did not need to see
and we isolated the communication adn showed the actual failure
of the client being able to resolve DNS.
So, yes, we do have scenarios.
Today will be scenarios that are put in to the modules.
Whereas tomorrow's, the modules each one of them is a scenario.
So I hope that helps answer your question.
Packet loss is a little tricky to capture.
Wireshark will give you clues.
One of the things that we're going to talk about in the next module is using the flow graph
which actaully the timing of that question is perfect
because the flow graph is going to be able to show you
specifically when you pick the TCP flow, how well it's perform
your application is performing. So for example, if you're trying to
send a request to pull a webpage
and you see in capture that the data keeps re-transmitting
or you're getting duplicate acts or
you're seeing a lot of re-transmissions,
it's likely that, that something may be getting dropped somewhere.
It could be something else but there's a way to, to isolate that
and the clue that, the clues that you're going to get
may be from Wireshark's flow graph.
So, we're going to get into that in the next section
but just real quick,
when you go to the statistics menu, when you pull up flow graph,
you can take a look at either all or displayed packets, the TCP flow,
and it will show you a very detailed view
of exactly what's going on from source to destination.
There's actually multiple IP's up here, source to destination.
That's what the arrow is showing you.
And it will show all the TCP communication.
Here I have a bunch of resets which could be an issue.
If you see a ton of resets coming back, there's obviously something wrong there.
If I see constant duplications of an act that may be something's getting dropped
and it has to resend it. So, there's some granular filters
you can look, put in which we covered in another Q&A section.
Or you can use something such as the flow graph
to try to figure out what's going on from one IP to another IP.
And see if that gives you a hint.
You can also go to the analyze menu and look at the Expert
where it may tell you, as an example
that you have duplicate acknowledgements.
And you have many of them.
They may be coming from the same IP, source to destination.
We have tons of suspected re-transmissions, that may be an issue.
We can have windowing problems where buffers are overloaded.
So, all of these things basically could relate to packet loss.
And the more that you dig in to the tool and figure out specifically from one IP to another
where you may think there's a performance issue
by isolating re-transmissions, duplicated acknowledgements,
windowing problems. If you see all these stuff from something that's performing poorly
it's likely that you may have some, some packet loss.