16:40
2025-04-22 09:23:11
5:01
2025-04-22 09:42:41
3:06:56
2025-04-22 10:08:58
3:52
2025-04-22 13:53:28
2:14:18
2025-04-23 09:04:44
7:38
2025-04-23 13:15:25
Visit the Basic Network Troubleshooting using Wireshark course recordings page
WEBVTT
-->
package. Yeah. Danin, I can see you are there. How about him? Okay, I saw you are
-->
here. So, okay, let me try to help you to extract this. Okay, from here. All right,
-->
that's the file that we are going to use during the training. Okay, so back to here. Okay,
-->
let's go back to the slideshare. Okay, so now you have those files, right? Let's go
-->
ahead and get to it. All right, I think before that, I will give you some brief
-->
about the network troubleshooting. So maybe I want to hear about some feedback from your
-->
side as well, because at least I will have a brief understanding on what you are doing
-->
and what is your level and then how can I help you to understand the basic knowledge
-->
of the Wireshark. Okay, so network troubleshooting actually for my role. I'm not really like using
-->
the command line to Linux, but I'm mostly using Windows for network troubleshooting.
-->
And why do I need it? Because, for example, okay, let me give you an example. Sometimes,
-->
let's say I want to transfer money while the online banking app. So when I log in to the
-->
app, so when I select my front account and to account, let's say, I fill in all the
-->
information needed. When I click transfer, that's a very important process, right? Because this
-->
money transfer process. But sometimes I can see the spinning wheel is keep loading.
-->
Or sometimes I will see like, why no response from the maybe banking side? And suddenly
-->
prompt, oops, the transaction fell. Okay. And then I'm the client, I'm so worried about
-->
now where my money go on. Is that fail? But then my money was deducted from that account.
-->
So what should I do? So normally, if I'm the one who encountered this failure, or I'm receiving
-->
some feedback or complaint from the client, I would try to use a browser. Okay, let me show you.
-->
Okay, so let me go to the, all right. So let's say this is the website. So if I click something
-->
here, okay, so let me open the inspector and network. All right. If I simply type any keyword
-->
I press enter. So you can see there are a lot of information under the tab. So I will always
-->
monitoring the transaction here. So if I see there's an API call, clients send a request to
-->
the server side. So I will see like, for example, this one. So I will try to click on it
-->
and I will see the response and the payload as well, payload and also the response from the
-->
server. Sometimes the server will just return the 200, but some server, I think most of
-->
the server response were passing the content as well. So if let's say, okay, I'm not
-->
able to capture any failure. I cannot get any clues from the network or just a very
-->
brief information for me. It's not enough. So I will use some tools. I will use some
-->
command line. I will also go to the Azure portal to check the Azure configuration as well.
-->
So that's what I did. But then for the network engineering, I think what you're familiar
-->
is that. So, okay, later on I will show you, but let's see what is the network troubleshooting.
-->
So this is the process of identifying the problem and then do some analysis,
-->
analyze the logs, analyze all the capture packets, analyze any information that you
-->
collect from the website, from the browser, from the network analyzer tools and
-->
resolving the issues that affect the performance, connectivity or functionality of the network.
-->
And then, so why is it important? Because I think right now, now always everyone is
-->
using network, right? No matter what. And now AI is very popular. So whenever we have any
-->
questions, we will sometimes, I mostly will ask chat GBT, Gemini or any like co-pilot
-->
tools for whatever purpose. So we are using network in every day, even in every minute.
-->
So it's very critical for communication and data access. And so let's say our client
-->
got some downtime or issues and affect their productivity, business operations or security.
-->
So it's very, very serious issue is a very, very critical problem and matter. So it will help
-->
it will cause our company to lose the money and the business. Right. And then so we need
-->
to like be proactive to do some troubleshooting to help to prevent the long-term issues.
-->
And what is the common network issues that we are always encountering?
-->
Okay. For example, okay. So I will use some example, why inability to connect to the
-->
internet or local network. So this was happened if the Wi-Fi drop, but then is it always
-->
happened? Not really. But it will happen mostly in my case is that when I connecting
-->
to the virtual machine or if my client is using the virtual desktop and for their,
-->
maybe for their assessing like connection to the application that we develop. So
-->
sometimes it will happen. And it's not only like internet drop due to the firewall policy.
-->
Sometimes it will always do to the slow network speed as well. Okay. So specific websites,
-->
not accessible, DNS error or device unable to communicate is always happen.
-->
If yeah, if the connection or internet got some like latency issue, or maybe the firewall
-->
will drop or maybe the server site has no accessible like got this 404 or 500 error.
-->
Okay. This was sometimes happened in my daily tasks. So that's why,
-->
that's why sometimes we use some tools to do at least some first ground of the troubleshooting.
-->
So I think that tools, the common line, I believe Ham and Tanin will be familiar with,
-->
right? Are you guys familiar with the common line tools and using it in your daily tasks?
-->
Okay. So what is the normally, what is the OS platform that you use? Is it Linux or Windows
-->
or Windows? Okay. Then how about the tools that I showed you guys before, the network tab
-->
in the browser, the developer tool. Have you guys ever used the developer tool in any browser
-->
like do some troubleshooting or debugging here? No. Okay. So all right. I think it's cool
-->
because we have a different background, but I think that was reacted because if we send the
-->
request from client side to response, that's one of the way that I monitor the transaction in
-->
here. Okay. All right. So, okay. Back to here. So I think ping, everyone is familiar, right? So
-->
this is to test. We send the ICMP packets to test if a device is reachable
-->
and we can measure the response time. And then trust rock. So this is the comment
-->
which shows each hub between the source and the destination to identify where delays or
-->
drops happen can. All right. So for the IV config slash all, this is to view the IP settings
-->
to display and configure network interfaces. And then NS lookup. Okay. We, for example,
-->
if you want to get the IP address, so we will check if the DNS query is resolved correctly.
-->
And then wild shark, I think this is our main purpose today. We are going to use a wild shark
-->
to capture and analyze the packets deeply. But I think in this training, I will don't
-->
spend too much time on the troubleshooting, but I will drive it to the basic usage of the
-->
wild shark. Okay. So next state and TCP dump. All right. Okay. So troubleshooting methodologies,
-->
I think this is quite similar, no matter who you are. So it's either you are an engineer,
-->
any, and never engineer or QA engineer or developer. So first of all, whenever we
-->
encounter any issues, right? Okay. Let's say crank comprend, the performance of the
-->
application is low. So they can see, or they are not able to upload a map file to their website,
-->
or they are not able to upload the file or download file to their machine. So we will try
-->
to collect what is the problem in a very high level. And we will try to collect all those
-->
steps. And we will see, is it possible to collect those logs or reports or any symptoms? Okay.
-->
Understand when, where, and how often the issue occurs. Is it always reproducible or only
-->
happen in their particular machine or environment or windows or what is the browser type they
-->
Okay. So second, based on the symptoms or initial log, we are trying to, you know,
-->
like form a hypothesis. Okay. Is the device receiving a valid IP or is DNS resolution failing
-->
or is the wifi signal weak or could a cable report be faulty? So we are trying to get
-->
possible causes. So for me, I will usually like form a hypothesis like maybe the
-->
connection in between server and client is not stable. So I would at least try to
-->
reproduce in my local machine. If my local machine is also encountered that issue,
-->
that means I don't need to collect all those information from client side,
-->
but it's only happened in their side. I will try to understand. Yeah. I want to try to collect
-->
all those needed logs. Okay. And then isolate the codes. So what does that mean? Okay. This
-->
is important to narrow down the source, like try to connecting another device on the same
-->
network and use the tools like ping, ipconfig or our short to compare the healthy versus
-->
a faulty system. So do a comparison and check logs from router or firewalls.
-->
And then once you are able to get some clues, so we will try to implement a solution,
-->
maybe, okay, let's say restart the routers or switches or reassign the IP address
-->
or if the hardware issue or cable issue, we can repress or change it
-->
or adjust the file rules or DNS setting. All right. And then verify the solution. We need
-->
to make sure is the issue has been resolved. Can the user access to the internet? Is the
-->
performance back to normal or are the services responding properly? And then the final one is
-->
document and prevent future issues. So this is very important because we need to record what
-->
happened and how it will fix, what is the root cause and what are the lessons learned.
-->
So we can implement monitoring tool or alerts or plan for redundancy or improve the
-->
Okay. So that is the basic ideas of the troubleshooting.
-->
So I won't go into the deeper level for this, but I will jump into our Wireshark lesson now.
-->
All right. Okay. So I think first,
-->
so let's just talk about why you are here in the first place. So I think since you are using
-->
Wireshark tool every day, right? So Wireshark can be intimidating. So when you are looking
-->
at the network traffic, it doesn't really matter what you are looking at. It could be
-->
or maybe even you are using Wireshark to investigate the cyber security incident.
-->
But when you trigger the Wireshark, for example, let me open it.
-->
So you can see the packets keep increasing, right? So it's intimidating. So it's very
-->
capture to analyze all those information with the 6,000 records here. Okay.
-->
So when you are looking at the network traffic, it doesn't really matter what
-->
you are looking at. It could be troubleshooting network problem, right? Like what I said,
-->
could be a cyber security incident. So we capture a lot on the wire, but there's
-->
a lot whipping by like few thousand, 6,000 within just maybe 10 seconds. So it's easy
-->
to get overwhelmed. So even with a simple screen as like you see just now. Okay. So
-->
here's a lot going on. What the protocols matter and what filter do I set and what
-->
I really hone in to find the source of the problem and even get the proof of what happened
-->
during an attack. Okay. So before we jump into the course, I want you to open the pre lab.
-->
So right now we are here to do in this course to make Wireshark more accessible to you as a
-->
tool in a toolbox that can help you to troubleshoot and investigate incident faster.
-->
All right. So later on, I will need your help to open the pre lab. Let me show you.