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
United Arab Emirates - Basic Network Troubleshooting Using Wireshark
WEBVTT--> okay so all right so we're on the same page okay please open the pre-lap slow --> network pick up yeah turning already there um you know hem you can open the --> pre-lap all right okay good so in lesson two we talked about before --> interface so we are on this workshop basic training profile but this time I --> will let you to take a look at some basic statistic first before we jump --> into lesson three okay so here so you can see here is the manual bar right --> and there is a statistic tool here when you click on it you can see there are a --> lot of tools under this statistic okay so different information we can get --> about this big app by clicking on different tools here so first I will --> go to the conversation okay before I jump into a workshop okay so I will let --> you to see later on I will give you five minutes to take a look on the --> conversation and then analyze something that you found in the --> conversation is either on Ethernet IPv4 TCP tab and tell me how did you --> know and realize this PCAP file is having network slowness problem by --> looking into these traffic conversation records okay so let me hide it and --> let me open it okay here so to make sure you both and me on the same page --> please click the statistic and then go to the conversation you can enlarge it --> or maximize these windows okay they are one two three four five five tabs --> here right so you can see Ethernet is two IPv4 is only one and then TCP is --> one as well okay so remember yesterday we did some packet analysis right so --> we did let me open this is the packet list so from here we can see we only --> have one and two two IP address so let me take a look on the destination so --> we have two IP address which is 10.0.0.100 and then 172.16.0.13 --> so okay back to the default ordering so we can see this 172.16.0.13 --> actually is like a client to send a request to a server so the server is --> 10.0.0.100 okay so only two IP address in this traffic --> conversation okay so the protocol having TCP HTTP what else let me take a --> look okay these two so back to here we do have two internet records here --> and why we do have the three MAC different address one two three okay --> and then when we go to the IP report there's one record which is here just --> now in the packet list summary view we can see this 172 actually is like a --> client to be a client and 10.0.0.100 is like to be a server right so both --> them are communicate with each other and sending the packet okay so one PB --> six nothing TCP we have one and then the conversation is between these two --> IP address by using for a for client 80 for server okay there is no --> UDP all right so take five minutes and then let on we come back and tell --> me yeah maybe we can take turn to share about your fighting okay right --> Oh --> So this is just like a warm-up for you to look into the statistics tool. --> So I think maybe let us have some interaction first before I jump into the observation findings --> explanation. --> All right. --> So who wants to go first? --> I see Tanin is smiling. --> So are you going to be the first one to share about? --> OK. --> So let me open the Wireshark. --> Remember yesterday we are adding this column, delta time. --> So we can see the amount of time between the packets. --> And here from 100, 105 milliseconds for this packet, I think still OK for this packet. --> So and going next and next, we can see it's quite quick and fast for the following each --> packet to transfer. --> But here it's about 20 seconds. --> So we can see maybe it's a spinning wheel, it keeps loading. --> So it's something wrong here. --> And from this conversation, what do you find? --> Right? --> I'll pass it over to you. --> And you are the next, OK? --> Oh, you want to go first? --> No problem. --> OK. --> I'm trying to track. --> And then you can see here we do have the 1, 2, 3 packets. --> And here in Dota you can see 1, 2, 3 as well. --> All right, Ham or Tanin, any thoughts about this conversation? --> Duration? --> Ah, here, OK. --> So you mean too long, is it? --> OK. --> Right. --> Next, anything else? --> Ham says no. --> Then Tanin, anything else? --> B to A are here. --> Ah, OK. --> That bit is quite high, is it? --> All right. --> From B to A means from client to the server. --> Sorry, from server to client. --> So it means the application is a bit slow to respond. --> OK. --> All right, that's all? --> All right. --> OK. --> So OK. --> All right. --> Back to... --> Let me zoom in first. --> Now it's easier for you to see. --> All right. --> First, let us recall the memory yesterday. --> Just now I mentioned from packet 6, from the friend 6 to friend 7 here, --> when 6 jumps to 7, right, it takes 20 seconds. --> What does that mean? --> Means I waited for 20 seconds, over 20 seconds to receive the packet 7. --> What does that tell me? --> So the three-way handshake worked pretty quickly for the previous packets. --> At least about 100 milliseconds in the network latency. --> So my get was sent off to the server. --> Again happened pretty quickly. --> The server acknowledged the packet 6. --> From here to here. --> So how many seconds it takes? --> So it's about 218 milliseconds, right? --> So no one, I mean no one is calling and complaining just yet. --> But 20 seconds, that's something you and I would complain about, isn't it? --> Like when you see you wait 20 seconds for the server, --> means the application to be load is nothing there. --> You can see a view is keep loading, the spinny view is keep loading. --> So I believe everyone when they look into the page, they will ask why, what is happening. --> So that's what I like to call a scream punching slow. --> So when things spinny view on you and you are thinking, --> why isn't that application loading and what is going there? --> So this was due to the application here. --> When server responded to the client, --> so that means this problem actually is due to the application. --> The application waited 20 seconds in order to send the response back to the client. --> So let me open again the work conversation box. --> Okay, first question. --> Just now I asked, since we only have one client, one server, --> but why we do have one, two, three, three unique MAC address. --> So let me think, maybe let me open this like this. --> Okay, never mind, come to here first. --> Let us jump back to the first packet. --> So normally if you want to check the MAC address, we will come to the layer 2. --> So let's say first packet is from client to server 172.16.0.13. --> What is the source MAC address? --> You can see. --> Okay, let me compare with the catalog here. --> Okay, 0C here. --> So that means 172, 0C is means 172. --> And then how about 100? --> 100 is 6F. --> So these two are correct. --> Okay, let us go to the second packet. --> 100 now becomes source, means the server becomes source because it responded. --> Okay, let me open the conversation. --> So just now 100 here, the server is having 6F MAC address, but now it becomes 7F MAC address. --> See, this one. --> And then the client 13 is having the same, 0C, 0C. --> So that means these two here. --> Sorry, let me open the laser pen. --> How can I open the laser pen? --> Okay, never mind, it's okay. --> I can't find it today. --> But anyway, so why we do have three MAC addresses but only two IP addresses? --> That I will explain in detail. --> So back to the slide. --> So I review the result here. --> So we notice that we do have three IP addresses. --> So that's one thing. --> Second, when we see packet B to A is 0, means the receiver not reply. --> Whatever is A or who is the A or who is the B, when sends the packet B to A, A not reply. --> Means the receiver not reply. --> And just now Tony mentioned that the duration is too long because the packet actually is just 25 and 54 KB, right? --> It's not that huge data. --> But it took 114 and 156 seconds. --> So it's quite long. --> Third finding is about the bitrate. --> What is that mean? --> The bits per second, which is BPS. --> So 1737 bits per second is very slow. --> It's a slow data transfer. --> 2750 is even slower, much more slower. --> And this is a one way communication only, but it took so long. --> So what is the possible causes of this low network behavior? --> We assume. --> So remember, we formed the hypothesis. --> Even though we always say that don't make the assumption first, but then we have to expect what is happening. --> We have to form the hypothesis. --> What if, what if, if something wrong? --> What if something wrong? --> So something like we guess what is the root cause. --> And then we try to narrow down the issue by different scenarios. --> OK, first, packet loss or no acknowledgement means no reprise on the destination or from the server. --> Connection or routing issue, maybe network connection. --> It caused the device unreachable or unresponsive, like return 404. --> Firewall or security filtering, maybe preventing some responses from the server or from the application. --> Procrastal logging, OK, might be sending data that doesn't require a reply. --> So these are the possibilities of the causes. --> So let me go into the details. --> So no response traffic, 0 bytes from B to A. --> Both strings show these two strings. --> We have string 0 and string 1. --> And these two strings show 0 packets and 0 bytes here. --> So from B to A. --> Meaning the receiver did not reply. --> So what does that mean? What does that indicate? --> So I tried to find out four possibilities. --> So it's either network misconfiguration, like firewall dropping the responses or connection issue. --> It caused the device at the receiving end is down or unreachable. --> Or broadcast or unidirectional logging or ping message, right? --> So this is something that is weird. --> And then for the low bitrate again, these two are quite slow. --> So possibility is due to the retries or network congestion or limited link speed. --> So it caused the slow data transfer. --> And then long duration, it lasts for 114 and 156 seconds, which is long for such a small data site. --> So this indicates it's either a slow or delay in the network connection. --> So from this conversation, we already know this packet is having network slowness issue. --> This is extremely slow, especially for this bitrate. --> Very, very slow. --> Especially for the modern networks nowadays. --> So what is the suggestion? --> What is the troubleshooting solution when you are getting this packet? --> I would suggest, let's say, first thing. --> So I found there are three MAC addresses for only two IP addresses. --> Maybe, I am guessing maybe, there are some reasons. --> So I will talk about only one reason. --> Maybe it's due to the IP conflict. --> It's having duplicate IP or misconfiguration for two machines or two devices on the same network. --> So maybe they are externally configured with the same IP address. --> But they are having their own unique MAC address. --> So what is the reason? --> Maybe it's cloning. --> Maybe it's for the DHCP. --> Maybe they are using the manual static IP settings. --> So it causes two devices having the same IP address. --> And what is the consequences? --> It may cause the network instability or drop connections or slow network symptoms. --> So what can we do? --> We can check if the destination MAC address is valid and active. --> Because maybe it's due to the connection. --> So we can try to ping the MAC address. --> And then we can use the filters. --> For example, here. --> Maybe we can try to check whether it has the ICMP ping or DNS or TCP.analysis. --> Maybe here. --> Whether it has retransmission packets or not to check for the errors. --> So for this pre-lab, we don't have this retransmission or ICMP. --> But in the tomorrow's session, I will show you on those packets. --> For example. --> And then run a ping or traceroute to the destination to test the connectivity. --> Or verify the Ohio rules for the endpoint behavior. --> All right. --> Back to the conversation. --> So here. --> In total, we receive 123 packets. --> So from here, there's no filter there. --> So it means the total packet size is 123. --> So it's matched with the conversation here. --> And then here. --> We do have 55 and 68. --> So that means in total it's 123 as well. --> It's correct. --> And let me check. --> The bytes here, 25 and 54. --> So in total, this 123, the size is 79 KB only. --> So it's a very small data size. --> So all the results here, the values from packet A to B, bytes A to B, actually is exactly the same as here. --> You can see. --> Here. --> So the duration is taking 156. --> And the bits per second, the bit track from A to B is taking 1268 bits, 2748 bits. --> So it's either you are looking into the IPv4 tab or Internet tab. --> Actually, it's the same. --> You can find something wrong by looking into the duration, the bit track, bits per second, and match with the data size. --> So that is the high level. --> I mean, the basic ways on how to looking into the problems. --> So if you think there are like a bunch of the packet list is too much for you to have a quick look on the traffic, --> just go into the conversation and take a look on this. --> This is the summarize of the whole lot of packet list. --> OK. --> So, so far, any questions or comments you want to talk about? --> If no, then I will get you to jump into the quiz. --> Simple questions help you to know, recap what we have learned yesterday afternoon and today. --> OK. --> Back to the slide. --> OK. --> Before that, OK. --> Before that, so Ham and Tanen, I want to maybe let me know a bit further about what is the tool that you are normally use for your analysis task. --> We do have a lot of tools, right, under the statistics here. --> So what is the tool that you are constantly using? --> Sorry, which one? --> Oh, four graph. --> OK, four graph. --> This one. --> OK, a little bit on the four graph. --> OK, what else? --> OK. --> Oh, this one. --> Which one only you are using on round trip time? --> OK, OK. --> All right. --> So round trip time and the four graph. --> OK. --> All right. --> So we do have this topic in the following lesson. --> All right. --> So I will. --> I think you already get this slide. --> OK. --> So you can click on the link. --> I will still share the link in the chat. --> Please open in a locker in a locker let up. --> I'm sending the link in the chat if you cannot find the slide. --> OK, just five questions. --> I hope you get a high score compared to yesterday. --> Try to answer it properly, one by one. --> Think about it. --> Just a quiz for your fun. --> OK, we take 10 minutes for this quiz. --> OK, after that, let us have a quick discussion about the quiz answer. --> And then we take a short break before we jump into the new lesson. --> OK, come back to you at 9.50. --> All right. --> Finish. --> OK, sure. --> All right. --> Let me take a look. --> OK, I found it. --> Sorry, the tech. --> Few seconds. --> OK, I can see your answer. --> So all right. --> OK, let me on the camera. --> So the first question, the time column. --> So what is the purpose of adding a time column in your wire shock? --> Not is not the data time. --> This one is about the time column, the default column. --> Yeah. --> So actually is to highlight the arrival time differences between packets. --> Right. --> So for example, we can see this is starting from time 0.0. --> And then it's gradually increasing. --> And the total duration is 156 seconds. --> So that means the arrival time for, for example, for packet 3 is 106 milliseconds. --> Yes, it's not highlight the current timing. --> It's highlight the arrival time for each packet. --> OK. --> So how can you OK. --> Both of you are correct. --> Turn off the default current reason. --> It's a magic icon here. --> When they accidentally cricket while everything is gone. --> So you will feel shocked. --> What happened? --> But you click it back. --> The current rule that you already said will be come back. --> OK. --> So remember, we can customize the current rules by using this current rule. --> You can surf to the customized profile. --> The personal profile. --> Or copy from the default one and then repress or override the duplicate one. --> So move on. --> Why would you add a specific values as a column in my shop? --> Create custom protocols. --> OK. --> So that question means. --> Let's say. --> Let's say. --> I'm looking into the packet. --> First packet. --> This is the same frag. --> Like it is sending from client to server. --> So second is responded by the server. --> So I want to know what is the sequence number? --> What is the enumeration number? --> So that's why I expand. --> The TCP and then adding this column into here. --> So this is the questions. --> Means why I need to add a specific value as a column in my shop. --> What is that purpose? --> It's helped me. --> It's helped the network engineer or maybe protocol analyst or task engineer. --> They're able to highlight what is the important information for our quick analysis. --> So it's not to create a custom protocol for analysis. --> We are not creating the custom protocol. --> We are looking into the protocol from the packet summary. --> OK. --> So why are our shop proposals useful for our analysts? --> Why the profile is important? --> Because they enable faster analysis by hiding the essential packets like the critical one. --> So when you. --> We are not customized the TCP behavior. --> Oh, OK. --> Different color schemes is the coloring blues. --> So this one, if we are creating the customization, let's say now. --> I. --> I open the mesh file profile dialog and from here I can add or remove. --> So means when I add a new profile here, it's under percent attack and then it will save everything in the current user interface, including the filtering button. --> Do you still remember, for example, that TCP and then filter is TCP dot analysis dot frags. --> So everything in here, including the coloring rules. --> Everything, everything. --> If you rename the column at a column, it was still inside this profile. --> So that means it will include every customization settings into this profile. --> To be enabled faster analysis by hiding the important packets. --> How can you add a custom column in washout? --> OK. --> Assess the preferences or settings and navigate the current section. --> Yes, correct. --> So there are few ways. --> Remember, we can write just right click and then we click column preferences and we can add a column under the column tab or we go to the edit preferences. --> It comes to the same location. --> Or we just right click, apply as column or drag and drop. --> To add a column address. --> So there are few methods to add a column. --> All right, so that's it for quiz. --> Let me write it back. --> All right. --> Well done for your quiz. --> I think that answer score is better than yesterday. --> So I hope you still can remember whatever you learned till now. --> OK. --> So let me open the slide. --> No problem. --> Yeah. --> OK. --> OK. --> So in lesson three, we are going to learn the more deeper about the statistic tools. --> But before that, do you want to have a short break now or after the first topic? --> If now, then we can take 15 minutes break before we jump into the next lesson. --> Oh, you guys are OK to proceed. --> At least we talk about the first topic. --> It's up to you. --> OK now. --> OK. --> It's OK. --> We take 15 minutes and then we come back at 10, 15. --> OK. --> All right. --> See you later. --> Welcome back. --> OK. --> Are you ready to continue our lesson? --> OK. --> Good. --> So next lesson, we are going to learn more about the statistic tools. --> I do have a one lab, which consists of I think more than 10 questions in the end of this lesson. --> I guess we took more than one hour for answering that question and also review it --> because there are quite some questions we need to really take some time for you to find from different tools or different configurations. --> So this is not the exercise yesterday is the most straightforward. --> I ask you a question and give you some tips. --> Just follow. --> But today you need to take some time to think about it, where to find it, where to find the answer. --> OK. --> So I want to make this lesson three as simple, but then it's more interactive because we are using some graph or tools to look into the information. --> So we are still using the pre lab network. --> So never pick up. --> OK. --> OK. --> So you can open that pick up file face in your desktop while I'm go to the next page. --> All right. --> OK. --> So like I mentioned just now, we are proceed with less entry using the statistic tools. --> And at the end of this lesson, we are going to have a lab exercise. --> And that exercise contains of more than 10 questions which need your thinking and thought to find the question and sorry to find the answer from different locations, from different tools, from different settings or even the packet detail span. --> OK. --> So I want to make this session to be more interactive. --> So later on, if you get any ideas or findings, and then we can share with each other. --> All right. --> So why we need these statistic tools? --> OK. --> As we know, Varsha is not about just capturing and starring at the packets, right? --> Especially in the large captures like consists of more than a few hundred or one thousand packet list is a lot. --> So when the issue is not in a single or few friends, but maybe is spread in different part of the picket file. --> So it's a bit frustrating for us if it's huge and is I mean spread over in different location. --> We need to take a lot of time and effort to go to to go by step by step or one by one to look into the packet detail span. --> It's very annoying. --> So. --> And you also often need to look beyond individual packets to get a broader view or identify the patterns and know. --> Key in the filtering, maybe you are using the rack expression or the special characters. --> So although Varsha is not a statistical tool, but it includes quite some powerful analytic modules that you can use to quickly understand the traffic role structure. --> So, again, in this lesson, we are start looking at a series of the statistical tools which will group under the name our graph and also using this hour graph to identify the top talkers. --> OK, I found the laser pointer here. --> So and also that graph that you are familiar with is the full graph. --> And also the long round trip time graph. --> And I would also introduce about how to personalize your hour graph and also the time sequence graph under the TCP stream. --> OK. --> All right. --> So by using this graph, it can help you to see the flow in the way that you will understand the logics of the exchanges, even in a very large captures. --> So I would then show you on how to identify the different machines exchanging the information in your capture and follow the top talkers. --> So remember the conversation dialogue that we learned in the lesson just now. --> We learned how to follow the conversations and the streams, right? --> We have two streams, stream one and two. --> It has the unique stream ID to isolate the specific traffic of interest. --> OK, so it will help you. --> These tools will help you to go beyond the layer two. --> And you can learn how to identify the machines of protocols. --> For example, we do have the TCP in the pre lab. --> So networks only have a TCP. --> So we can see the number of the TCP transactions. --> The number we can see how many TCP transactions in that conversation dialogue. --> So the protocol tab is shopping with NEM instead of the least application or visualize protocol hierarchies throughout the entire capture file. --> OK, so you can modify the view. --> You can add a filtering to customize the graph. --> It will help you to spot the anomalies. --> OK, so when you get comfortable with the tools, I will let you to jump into the lab as a size. --> And probably you can customize the tools that we learn and credit and to retain the functions that help you the most. --> All right, so let's get started and jump into the first one. --> OK, so before we jump into the aisle graph, let me quickly summarize what a statistic can help you. --> So under this statistic manual, we can see a lot of different opportunities to see things about our packet capture is either to save a file or a live running file. --> So by using the tools, we can quickly to see the total packets. --> Remember the total packets one, two, three for this bigot file. --> We can see the total packets amount and the time means the duration and also the packet size in bytes that is sent in this network traffic. --> OK, and we can also see the comments. --> I'm not sure whether you know about it. --> We do have the capture file properties that I will show you. --> So I'm not sure whether you know about it or you use it frequently or not. --> But that I will show you. --> So in there, we can add a comment. --> So later on, I will also add a comment inside that property dialogue. --> So you can answer me while edit a comment and then save it. --> So I can go into a workshop in your desktop and then just check your answer. --> OK, so and also we can find the top talkers. --> That means who is the chat is device in your packet capture and also view the conversation and throw and even resolve the address for the clients and service in the capture or the life. --> We can also create a custom customized our graphs that those can be stored per configuration profile. --> Remember, we do have the customized profile. --> So in overall, this statistic manner is very, very powerful. --> OK, let's jump into the hour graph. --> All right. --> So before I proceed, I want you to open your desktop again and open a workshop. --> So go to the statistic menu and then. --> Mouse use a mouse to point to the hour graph and click it. --> So you will get the first grants of the hour graph by the default view. --> So in here you can see I already added some customized filtering. --> And also different color. --> So let me open a workshop and then I will monitor your desktop now. --> OK, I can see both you are there. --> All right. OK. --> So this is a pre lab slow network pick up file. --> Let me see. --> The surface I want to. --> All right. Oh, OK. --> I can see you have the TCP errors. --> Is that a filter that already exists in the packet file or you edit by yourself? --> The TCP errors. --> OK. --> All right, I think I start. --> OK, never mind. --> So right now, let me put side by side. --> Let me remove this column. --> OK, now the time is very important, very important. --> So. --> The why is this we can see there's a packet amount per second. --> Actually, we can we can switch different options. --> But normally I would prefer to use the second as an interval with the most. --> Because if you choose the millisecond, it will become very, very small interval. --> It's very hard for us. --> To do the analysis. --> So normally I would choose one second as an interval per packet. --> And also the X axis is the. --> Time the unit is the second. --> So from here, you can see, wow. --> OK, it's go up to how many packets? --> Um, it's about 35 packets during this in duration. --> From maybe 23 seconds until 25. --> So by comparing with this packet list. --> OK. --> OK, here from 10 the one second. --> OK, let me start it. --> OK, from 21, that means it's number 14. --> To 60 to 62. --> OK, so you can know. --> You can try to zoom in and zoom out. --> So 21, let's say this is 21. --> Yeah, so you can see how many packets. --> Around 21 seconds. --> So that is exactly match with the packet list. --> So do you need to count it by yourself manually? --> No need. You just look into this hour graph. --> All right, so. --> Don't need to spend a lot of time. --> I want you to tell me. --> I want you to tell me from this packet. --> The hour graph. --> Let me press zero. --> When you press zero. --> Once or. --> Or twice, you were back to the default view. --> OK, from here. --> Right here. --> Until 100. --> Around 125 or 23 seconds. --> What happened? --> And what's wrong with the. --> What's wrong with the packet capture? --> Can you share our idea? --> Only one feedback about this hour graph from each of you. --> Dunwin and Hem, I want you to talk. --> OK. --> All right. --> Any comments or any thoughts, feel free. --> No wrong or right. --> OK. --> Hem, now it's your turn to go first. --> OK. --> So. --> So what is your finding from the hour graph? --> Any idea? --> Packet loss. --> OK. --> From where you can see is drop. --> From where? --> You mean here? --> OK, from here onwards. --> OK, from 25 seconds onwards. --> Maybe. --> The packet is drop. --> OK. --> OK. --> Router. --> A firewall. --> OK. --> Because it's over the size that the switch can handle. --> Or the device can handle. --> So it will cause the packet drop or loss. --> OK. --> What else? --> Not turning? --> I don't have the exercise about the graph. --> But then I will have an exercise in the overall picture. --> OK. --> So never mind. --> All right. --> So back to the slide. --> I'm capturing the screenshot for the hour graph. --> I think you are seeing the same as mine, right? --> The screenshot. --> You do have the TCP errors with the red background color and the line color. --> And also the HTTP filter in yellow color. --> OK. --> Let me. --> Three-way handshake is not complete. --> OK. --> OK. --> So from where you can see the three-way handshake is not complete? --> In the packet list, is it? --> OK. --> OK. --> The same act. --> If you don't see the same act, pick it. --> OK. --> All right. --> OK. --> Good try. --> So I won't show this wire shock. --> I will use the screenshot as in the slide. --> I think it's the same as your screen. --> OK. --> Let me double-check. --> OK. --> OK. --> It's OK to ignore the HTTP because it doesn't matter. --> It's not related to this packet analysis. --> We don't have that error for HTTP. --> We only got the TCP errors. --> All right. --> Back to here. --> OK. --> So first, you can see, just now I mentioned, if you want to look into the smaller lever, --> you can change it to milliseconds or even larger. --> And you can try to zoom in and zoom out. --> If you want to go back to the, like ghostware too far off the screen, you want to go back to the default view. --> Just press the zero button once or twice. --> You will reset the graph. --> OK. --> So this is very, very handy. --> You can tell in the title of our graph means input output that we are working with a live capture. --> OK. --> So if you get the hour graph, normally I will set it into a PDF file or a big on the picture. --> Why I want to set it in the picture is because it's easier for me to attach it in a report and present to the client or any stakeholders. --> So that's what I did. --> If you want to attach this information, this information right on especially to send the data points on the graph as a CSV file for later use in an external program like Microsoft Excel. --> So you can just click the copy button. --> So now we are using one second is the interval. --> So what is our key observation? --> First, it's very obvious. --> The spike. --> Can you see? --> It's a sharp bridge of the packet activity seen between 15 and 20 seconds. --> It's picking at nearly like 50 packets per second. --> So again. --> So in order for you to look into the wire shock, you can apply different filter. --> When you apply different filter and you go to a static tool, that result may slightly different. --> It depends on the filter that you put. --> So by looking into this screenshot, you can see it's a spike. --> It's a sharp bridge. --> You can see this one is go to the top and then go down. --> Maybe after like one or two seconds immediately. --> So it's like a picking. --> And this birds is likely correspond to the man data transfer ordinary event. --> So what why it goes up and down is becomes a sharp bridge. --> Something maybe we need to take a look. --> OK, so after this, I purposely credit dissipate errors with this TCP analysis. --> I want to I want our graph to show what are the potential TCP problems in this traffic network traffic. --> OK, so from here you can see it's around. --> OK, let me open the hourglass so you can see it's around. --> You can see order because it's very small. --> OK, let me open again. --> You can see between 15 and 25 seconds and then at nearly like 50 packets per second in here. --> And also, again, it's about 70 seconds until 110 seconds. --> You can see the dissipate errors go up. --> So those errors may indicate maybe the packet retransmission or we do receive duplicate knowledge from the server or zero windows segment or other TCP level issues. --> That one was the fighting and observation. --> OK. --> Just now, I think I mentioned that all time you mentioned that is is like a sharp brace is a pig. --> But then after 25 seconds until 150 seconds. --> Here, what happened is a quiet period. --> Very few packets are observed is idle is like kind of idle period. --> So it's a long period of inactivity. --> What happened? --> What happened to this idle stage? --> It may be due to maybe a stall connection. --> It's still to the network congestion. --> Maybe it's due to like switch problem, like what I mentioned, or firewall. --> It broke or it delayed the application later. --> OK. --> So that's what we encounter. --> In this packet capture and observe it. --> OK, so this TCP analysis are actually is a very important display filter because it includes the things like retransmission out of orders or duplicate. --> So, again, we can see what happened to the hour graph to showing that some symptoms of a slow or problematic network. --> The TCP errors are long idle period. --> OK, so I think that's the fighting for this pre lab slow network and then how to customize it. --> So I want you to play around with this. --> I want you to customize. --> Maybe I will give you a done. --> I'll give you a filter. --> All right. --> Open your washout and I'll I'll graph. --> I want to I want you to add multiple lines with different display filter. --> And then set it as a JPEG file and back to here. --> So let's say. --> Just OK. --> We do have one, two, three, four, four potential TCP errors. --> And just now, Tony mentioned that. --> Scene act respond, right? --> Maybe it's not complete because. --> We lost the same act respond. --> Remember, yesterday we learned how to add the filter for filtering the scene act. --> So if you forgot the syntax, just click any one of the same act respond. --> Expand the TCP. --> And then expand the frag and then drag it. --> OK, now we can select and select it because we want the two, the two filter condition applied. --> OK, so copy it and then put inside your hour graph and show me. --> Save it as a PDF file or JPEG file and then let our check. --> OK, go ahead. --> A little bit lower. --> Let's try it a little lower. --> Just a little bit lower and we'll have it show up. --> Just a little bit lower. --> Okay, I can see you've already added. --> Can you generate as the PDF report and Dhani, maybe you can generate as a JPEG or PNG file --> as a picture. --> And then open the exported file and show me. Okay, all right, I saw it. --> How about Ham? You can generate as the PDF file, PDF okay. So open the PDF file --> that you exported. Okay, all right so while waiting for Ham to open the PDF --> file. Dhani, go back to the hour graph. Okay, try to zoom in. Zoom in. Just scroll your --> mouse closer. Like make it larger. Zoom in, something like that. Okay, something like --> that. Okay, so show me how to back restore to the default view. So right --> now I can see, wow, I want to see the, no, I don't want to see this oral --> picture. I want to see the default one, the original size. Okay, no, don't use --> the dialog. Use your keyboard. Press the zero button. You can try to press one --> time zero button in your keyboard. Just press zero button. Okay, so how many --> times you press? One time or two times? I cannot hear you. I think you are muted. --> Okay, good. So press zero button one time. You are back to the default view. So Ham, --> show me your PDF file. Okay, okay, I saw it. All right, so this is something that --> I normally use and attached in our report to show that, okay, I can --> explain, put some observation in the notes there. The either period with --> the TCP error if you want to show the error with the highlighted color. So --> it's able to tell that the user like something wrong because it has a --> quiet period. And also the TCP dot nsys dot rex, this is something like --> potential problems with free transmission, duplicate acts, etc, etc. Okay, all --> right, so back to my slide. Okay, so we're already done to personalizing the --> IO graph. So I can put the graph name as TCP act if I only want to see the --> filter with the frags dot act equal to true. And then I can choose --> different style. So see, it's very interesting. I can see a lot of dots --> inside the graph. So the IO graph actually is very powerful because you --> can customize it with entering many different deep spray filter. It's not --> capture filter, instead it's a display filter. After you capture the --> file, then you just filter it with the displaying packet list. So we can --> set it as a simple packet visualized graph. It depends on the --> filtering that you filter here. So for example, in our packet --> summarized list, we do have 123 packets. But then in the --> IO graph, you want to filter it become smaller size, then you just put it as --> different filter here, right? You can reduce the size of your graph. So let's --> say, okay, I want to like, I want to get the filter with retry. If let's --> say I have the reset packet, I have the retransmission packet, you can try --> to fill in different filter with different coloring of the line or bar. --> Okay, or if I want to see, found any like ICMP --> packet, I can also filter the displaying filter in here with the --> HTTP or DNS. If maybe, I'm assuming maybe the server will or the client --> will use that different protocol for the TCP errors happening. Okay. --> So there are many, many filtering that you can put. So just third note, if you --> have a list of common filters that you normally use, you just put --> inside a note and you can just copy paste. Or it's very hard for you to --> like realize, okay, which is the powerful or useful filtering that --> it will be helpful for your packet analysis task. Okay. I think I won't --> ask you to do any exercise for this personalizing our graph because we --> already done it in the exercise just now. Okay. It's just a quick --> exercise because I want you to experience it by generating our graph --> and exploit is a different file extension like PDF or JPEG. Okay. --> All right. Okay. So the capture file properties that I already show you --> just now and mentioned that we can add a comment in here. This is the --> comment. I won't ask you to do as a size right now for this capture --> file property because we do have the lab after that. Okay. Let me --> using because you can see the statistic here. Well, it helped us to --> summarize everything. So what happened? Okay. For example, for --> example, I want to compare. I want to compare the disparate --> capture with the, okay, the disparate filter with the capture --> filter. And now I don't enter any disparate filter yet. So those two --> statistics are exactly match. But what if I want to find those --> potential TCP errors and then open again the capture file properties. --> So it helped me to refresh the statistic again. So it's easier for --> us to do the comparison. Okay. So by using this example, let me end --> the slide sharing first. Okay. So, okay. From here, what you have --> seen? What have you seen? Okay. Maybe we look from here first. --> Okay. So I can know it starts from when and what time. And it --> lasts and ended at when and what time. And how many seconds it --> took in the overall. So now I can see it took two minutes 36 --> seconds of the total time for the capturing. Okay. So if I --> want to analyze the troubleshooting, slowness of the --> network or a performance issue. Okay. So a few key things to --> stand out. Only four packets they spread out of the one, --> two, three capture. So we might suggest to the few --> traffic. So this is what I purposely did to highlight the --> display statistic here. Okay. So the average packet size is --> fairly small. How many? Size? How much of the size? It's --> six, three, nine bytes. And the overall traffic rate is --> very slow. Why I know that? Because remember, we do have --> the bit rate, bits per second. And now it's showing the --> average bits per second is four, four zero one seven means --> about four Kbps. So this is that means the traffic rate is --> very slow, very low in our overall traffic rate. Okay. --> So this consider low traffic. And I can add some --> comment. Okay. So let's say I want to add a comment. So --> low traffic with --> only four Kbps. Okay. What else you want to add in the --> average packet size is fairly small. It's only six, three, --> nine bytes in total. Maybe the overall traffic rate --> is quite low. --> Okay. About. Okay. So anything else? --> Okay. So --> okay. One more thing to highlight. Filter the --> display. --> And this is right. So why I need to add the comment in --> here? Because when you save it, and then you can --> set the oral picket entry file again, and then send to --> your client. So from there, they don't need to know --> maybe you send while email. For example, you put all --> the notes in the Excel file or Word document. When you --> send while email, they will forgot where to store or --> maybe they overlook on that email. But then if you --> send out to this big app entry file, they can easily --> to read all the comments or the findings or observation --> by looking into these comments. Okay. So from here, --> we can also know like what are the hardware or OS that --> you capture, but here is unknown. Okay. All right. Let --> me close it. Okay. So far, any questions or comments? --> Okay. All right. Then let's proceed. Okay. So the --> third powerful tools is the end points. Okay. So --> let's say I want to identify the top talkers. So who is --> most talkative device on your network? How can we do? --> Have you ever used the end points for the analysis? --> Have you? Okay. Maybe let me show you where is the --> end point. Yes. So have you used for your analysis --> task? For your project? For your business case? No. --> Okay. Never mind. Maybe it's good for your knowledge as --> Why we use this end point? Because sometimes we want to --> find which devices are talking the most. Is it server or is --> it client? So from the end points, it will show you. --> Okay. It will show you like all the tabs, which --> includes the internet, IPv4, IPv6, TCP and UDP. It's --> This is the conversation dialogue. And this is the end --> point. Okay. If you compare both, you can find the --> tabs are exactly the same, but the numbering is --> different. So here, this is the conversation. This is --> a conversation, traffic conversation. So it will help --> you to summarize. But the end point, I want to see how --> devices. I don't need to guess. Okay. One, two, three, --> and this is the same as the address A source. So that --> means only three unique end points. I don't need to --> like check it manually step by step. I just go to --> end points, then it will help me to summarize how many --> IPv4 address, how many internet MAC address. So that --> I can find easily and compare with the conversation --> here. Okay. That's the difference. So. Okay. It has --> the packets, bytes and the direction. Okay. Okay. Let --> me go to here. Yep. We do have the total packets --> as well in every tab. And you can see how many --> packets in here sent by this device. Okay. Let me --> hold on. Let me clear the filter first. I forgot to --> clear the filters. Okay. Again, come to end points. --> Yeah. So that is the total. Right. So how to know --> who is the most threat is like the talking the most --> device. Okay. Let's say, sorry, zero C. How do you --> know from this dialogue? I can see one, two, three --> packets from here. Okay. Good. So if let's say I --> open again the conversation. Okay. So I can see --> this address, 172.16.0.13 sent to the address --> IP. It's one, two, three packets in total. So --> let's back to the here. Okay. Go to the top one --> when I click on the first one and then check on the --> MAC address. Okay. So zero C. Zero C here. So what is --> the IP address of the zero C? 16.0.13. Okay. So by --> comparing with this, is that correct here? Okay. --> So this 172.16.0.13 is the most talkative device --> because it talk a lot. It's sending a lot. And then --> these two actually is belongs to one IP address but have --> different MAC address. So maybe they are from different --> devices. Maybe or maybe misconfigured in the machines. --> Okay. So if I go to the IPv4, since I mentioned they --> have one IP address have different MAC address. So I'm --> not sure whether this IP address is belongs to one --> device or two devices, even though it's sending one, two, --> three. So as a conclusion, I can't judge is the most --> talkative one, but I can determine this source as a --> client is the most talkative device from the packet size --> that I can find here. Okay. All right. So it's very --> simple for the conversation. I am only using this as to --> find out like who sending the most maximum packet size --> and then who are the most active device in the --> traffic, in the network traffic. Okay. All right. Next. --> What else? Okay. Just now we know. Okay. Back to the --> source is the client. Destination is the server from the --> SYNFRAC I can see, right? Because SYN is sending by --> client. So if let's say I want to see the, I want to --> identify the talk talkers. What is the other methods that --> I can use? Okay. Let us go to the statistic, IPv4 --> statistic and select this destination and ports. So in --> here, I can see all the list of the IP address --> destination. Now this is so-called destination IP --> address and the ports number. Yeah. Port number. They are --> with. And if you collapse the protocol, it's only showing --> TCP. Why is only showing TCP instead of having HTTP, --> HTTPS and other protocol? Why? That means in this network --> traffic, it's only have the TCP conversation by sending --> packets. So from here, I can see the size, the number, --> sorry, not the size. The size will be misunderstood, --> will be leading to misunderstood. So I want to --> see how many a month of the packet is 68 is 55. So this --> is the destination. So I will see. Okay. From the --> port to the client, the client received 68. From the --> client to the server, it received 55. So this is --> something that I can try to list it out. What are the --> protocols and what are the packet amount that send to --> the destination? Okay. So this is the optional method --> that you can check on the destination on port. But for --> me, I would say the most preferred tools that I'm --> using the most is the conversation tier. But if I --> want to know how many devices, I would choose the --> endpoints. So the destination and port that I'm showing --> just now is to highlight like if you don't have the --> duplicate IP address with different MAC address. If --> you don't have that problem, yes, of course, you can use --> the destination port. But you do have, it will make --> you more confused. Hey, why only one IP address and then --> how can I identify the most top talker? I don't know --> because it may be come from different devices with the --> duplicate IP address. So it will lead to misunderstanding. --> Okay. So it's up to you to choose which tool you can --> use. Alright, next. Okay, so we do have the --> photograph and also we do have the time sequence --> graph. What else? The round trip graph. So, and --> lastly, we do have the lab. So I don't think I will have --> the time to do the lab one, but we try to finish --> one photograph, TCP time sequence graph, and also the --> round trip time graph in this morning session. And then we --> can have a lunch break. So lunch break, you still prefer --> one hour, is it? Not too rush for you. And then for --> today's session, I prefer to have less break time and --> then you can end earlier. Okay, you have the event --> tonight, right? Oh, okay. Good to know. So when you're --> back to Thailand, is it Friday or Saturday? Oh, it's --> rush of 6 p.m. Okay, so we still have time. Okay. --> So as I remember, both of you said you are familiar --> with this photograph because sometimes you will use it. --> So photograph actually is for me is quite simple --> because it's showing all the flow in the traffic --> conversation. But I would like to know in your use --> case. Okay, I think it's your talking time --> right now. I want to know why you use this photograph --> and then what is your use case or scenarios --> and what are the type that you mostly use --> to understand your packet. Alright, so I will pass --> to any one of you to tell me or you to briefly --> introduce. Okay, you're okay for just for teaching --> purpose. Okay, so what type you are using? Are you --> using all flows or specific flows type CP flows? --> Okay, can you tell me from this TCP flows? --> And we do have these two IP address, right? So --> okay, let's say I will ask Tony. I don't know. --> I don't know how to identify who is the client, --> who is the server and why. Okay, can you answer --> my question? Okay. So that means 172 server. So that --> means whoever received the SIN packet is the server. --> Okay, alright. So, okay, next question. --> Okay, since I know 172 is the client, --> 100. Okay, I call it 100 server. So I know --> 100 server. 100 is the server. But how do I know --> the server already received the packet successfully? --> Ah, okay. SINAC is the responded by server --> because it will tell, hey, client already --> received a packet and already acknowledge it. --> Okay, yes. Yeah, okay. So why the client is using --> 61330? Okay. Okay, good. So, okay, client --> receive. And then will the client responded --> to server to tell the server, hey, server, --> I already receive your acknowledge. So no problem. --> How did I know from this program? --> Will the client tell the server that, hey, server, --> I already receive your packet, already receive your respond. --> You mean here? Okay, alright. Okay, just now who mentioned sequence? --> Okay, can you explain further about sequence number? --> Is it the sequence number that you mean? --> Okay, what is the difference between acknowledge number and the sequence number? --> Hello, can you hear me? Okay, um, --> um, like, I think Dhanin answer the right. --> So the sequence number, let's say from here, --> this is the number of the first part of the data in the TCP segment, right? --> So, um, okay, I give you an example. --> Okay, so, okay, from here is starting from zero. --> And the TCP segment carries, for example, --> for example, it carries 100 bytes of data. --> So what is the next sequence number? --> The next segment will have a sequence number of one, --> uh, sorry, zero plus 100 means 100. --> Do you get what I mean? Okay, so this is, --> okay, again, let me highlight again. --> So it's the number of the first part of the data in the TCP segment. --> So if let's say, um, the first segment, --> I started from sequence number equal to zero. --> And then I know that this is the TCP segment is sending 100 bytes of data. --> So the next sequence number, if I receive it correct, uh, --> successfully, it will start, it will start with zero plus 100 means, uh, --> 100. Okay, 100. --> It was started with 100. --> Okay, then how about a knowledge number? --> Okay, let's say sequence number equal to zero and our channel equal to one. --> Okay, so, okay, so if let's say, um, --> if the client received the unless the segment with a knowledge number one, --> here is one, right? --> It means the sender receive all data up to byte, uh, one. --> And it expecting the byte one in the next segment. --> Okay, here is the packet size that the server, --> the, sorry, that the receiver can be received. --> Do you get what I mean? --> So, okay, maybe next question. --> Um, okay, maybe I don't ask any question, but tell me from that graph what you can see, --> for example, from 105 milliseconds and then suddenly jump to 20 seconds right here. --> And then from sequence number equal to one and suddenly jump to 1461. --> I was asked, hey, what happened? --> Why suddenly the sequence size, uh, --> is plus 1400 is a huge difference. --> What happened? --> So, think here, one, two, three, four. --> Okay, here, 108. --> 108. --> Okay, remember I mentioned that I found something wrong because the length size of the --> is too huge, one, five, one, four. --> And then it has a problem. --> So it's not able to send it out successfully. --> It has split into two packets and to be continued sending because --> the packet size limited during capture. --> So from here, I can see the sequence number jump from one to 1461, --> but then our natural number is one. --> So that means there is something wrong from here to from here to here, --> and also from 108 to 218 here. --> Sorry, from 218 to 20 seconds. --> So this is something that I need to analyze further. --> So if you click on here, see, it will auto-highlight the problem, --> the packet in the summarized view. --> Okay, so again, sequence number is to identify the first byte in this segment. --> So it was started with 1461 in this segment, and it's from sender to receiver. --> Okay, to indicate what is being sent, and it's randomly generated as in the start --> of the connection. --> So if let's say it's 1461. --> So meaning it's sending the byte 1001 onwards. --> Okay, 101 onwards. --> So it's sending 1461 bytes onwards. --> And then what is the analysis number? --> It indicates the next byte expected from the other side. --> The next byte is better from the other side. --> Okay, it's from receiver to sender. --> Send server, send the analysis to who? --> To the client. --> So it means from the receiver to sender. --> And tell what has been received. --> Okay, what has been received? --> I already received one. --> I already received 1519. --> So it's usually zero until first segment is received like here. --> I already received one segment. --> So my analysis number is one. --> So it means number of bytes received in analysis. --> Okay, for example, if I put let's say 1522. --> What is that means? --> Okay, I already received 1521 bytes. --> I already received up to 1521 bytes. --> So I'm expecting the bytes starting with 1522. --> Okay, so analysis means I already received how many bytes in the previous segment. --> And then I will start with 1522. --> And then sequence number means --> I identify from which byte, the first byte in this segment. --> So it was started with byte one onwards. --> Okay, it's a bit confusing but actually this sequence number --> and knowledge number is quite helpful for our analysis in the last session. --> Okay, all right. --> So what else? --> What else you are using this --> photograph for any purpose of your project? --> That's it? --> Okay, so the photograph can easily tell us like the total amount of time --> is being elapsed. --> For example, 156 seconds is about two minutes and maybe 36 seconds. --> And also the list of the knowledge and sequence number. --> So you can export it into PDF or Jetpack PNG as a picture file --> and then attach in your report as well. --> So if I want to see the overall flows, --> so it's a bit complicated if you compare with the specific photograph --> with different specific type. --> So normally I won't use the offers unless I want to know. --> Okay, apart from TCP, what are the protocols that are used by this network traffic? --> So I can see, oh okay, it's sending HTTP because it's using port 80. --> So it's not HBS. --> It returns 200 means okay, no problem, successful. --> But it's not important for my network analysis --> unless I got some error code with apart from 200. --> But from here it's easy to tell me like okay, --> so from the client to the server, it's not successfully. --> So I'm keep sending because packet size is limited. --> I'm keep sending. --> Okay, see there are a lot of continuation until when. --> So we have to click keep scoring down. --> Let's say I back to this packet nine. --> This is around 20th point. --> This one up here. --> So yeah, from here you can see there is something wrong. --> The server responded very slow and it keep continuous sending --> because of the packet size limited during the capture. --> All right, okay. --> If you want to limit the photograph, --> you can put a display filter here and then click the check. --> For example, if I only want to see those problem with, --> okay, let's say contents continuation. --> It will refract exactly the same as our summarized bill. --> But if you want to see like for example, --> I want to see the frags. --> Equal to only. --> That means I want to see from the server to the client. --> So it can help you to narrow down the analysis scope. --> All right, okay. --> That's it for the photograph. --> So by using this program, actually, --> it can help us to visualize the sequence of the packets. --> Exchange is very important in the network traffic --> between the endpoints over the time. --> So what is the benefit or advantage of this program? --> It helps us to understand the communication in sequence --> and then it helps us to troubleshoot on the handshake --> like Danny mentioned, the three-way handshake problems, --> the TCP three-way handshakes problem. --> For example, like the retransmission. --> So it helps us to see some delays or other packets --> in the complex exchange or any TCP errors. --> So because we can see it shows the protocol layers, --> different protocol like TCP, UDP, DNS, and straw. --> And it also shows the direction, right? --> Direction go and back. --> And the flags like SYN or ECH or SYN ECH and etc. --> And it also color and order communication line --> like a letter diagram. --> So it's quite easy for us to see the overall communication flow. --> Okay, all right. --> So next, I'm also using the same PCAP file, --> the pre-lap slow network PCAP file. --> So it's the same. --> We can use the flow of TCP data, which is under here. --> I'm using TCP Trash because it's more detailed than the Stevens. --> It's more or less the same, but TCP Trash is more detailed. --> So I'm selecting this timescreen TCP Trash --> to see the summary of the graph problem. --> So I already attached the summary of the observation. --> Can someone help me to read it out? --> What is the observation from different aspect from here? --> What you have seen? --> Maybe Tan-Yoon, you can be volunteer. --> Okay, so I have one, two, three, four, five. --> Five observations. --> So maybe you can translate by using your own language. --> I mean, using your own way to describe about --> what you have monitored and observed by using this TCP graph. --> Okay, so I try to give you some example. --> The total span is about 160 seconds --> because it's more than 150 seconds. --> So we can see the measure rising here in the data transfer, --> and it stopped around 25 seconds, right? --> No more data is being sent in the x-axis here. --> And then in the y-axis, this is the TCP sequence number in bytes here. --> Sequence number in bytes. --> And this is the time in seconds. --> So it represents the cumulative number of bytes successfully sent. --> So how many bytes the server has been sent about? --> How many kb or how many bytes in total for the server already been sent? --> So from here, you can see it's about how many? --> More than 65,000 bytes or about 63.5 kb, is it? --> So this is the difference between y-axis and the x-axis. --> So I try to make it slow. --> Okay, so this is the key observation. --> The initial data transfer is from 0 seconds to 25 seconds because it stopped here. --> So data is sent steadily in steps from 1, 2, 3, up to 25. --> It's stable. --> So this represents normal TCP segment transmission. --> But then is happening the sequence number practice like a sudden practice after 25 seconds. --> So it indicates sender stop transmitting more data. --> Or someone is either client or server is waiting for the segment. --> Maybe, maybe is the client is waiting for acknowledgement. --> So it could imply the receiver side delay. --> Okay, receiver side delay or window size limitation like what Ham mentioned just now. --> Or congestion, network congestion or any packet loss or retransmission stalling progress. --> Or it's simply the data transfer finished early but the client is still waiting. --> Okay, let me see the green light here. --> Okay, green light means the acknowledgment from the client, the x-ray ACK. --> So it catches up to the data quickly after initial delays. --> But it stops updating after the data ends. --> Okay, so this is what is expected because we already have the key observation --> from the first perspective. --> So if you hover the data, bottom line here, see. --> It helps us to summarize 68 packets already sent from the server to client. --> From the server to client. --> And the 55 packets is from client. --> It's likely on x-ray, the ACK. --> Okay, so it shows that this was relatively short session. --> Maybe the issue is due to maybe a slow network or delay x or slow start behavior of TCP. --> Or retransmission is not visible directly. --> So it could be inferred if jump or overlap is in the line. --> Alright, so that is so-called time sequence graph. --> And it shows green light means from client. --> Show the black line means from server. --> So what is the observation in here? --> So Tanim, can you help to repeat again what is the key observation by using your own method? --> Duration, yes, it's about how long for the duration in total? --> You mean drop down? --> Or you mean here? --> It's dropped, okay. --> It's dropped at 25. --> Means like something stopped there. --> The data transfer stopped there. --> Okay, so anything else from what you observe? --> One more thing. --> Sometimes when we look into a time sequence graph, we might get confused. --> Does it represent client or server? --> So actually at the top in here, sequence number means TCP trust is actually from where to where? --> Here, yeah, yeah, sorry, the client. --> So this one need to be noted. --> And also this is the graph title. --> So all the packet size here, if you compare with the conversation dialogue, --> endpoint dialogue actually is the same. --> See, 68, 55. --> 55 is from what always means by 55? --> Still remember? --> It's from server or client. --> Okay, good. --> And 68, okay. --> All right. --> So, okay, again, can you give me an example like, let's say, for example, --> first segment, the sequence number is 1,000. --> If this packet has a sequence number of 1,000, 1,000. --> Oh, this packet. --> Okay, I have packet 1. --> I have a sequence number of 1,000 and I am sending 100 bytes. --> Okay, 100 bytes. --> So what is the sequence number of the next packet? --> Okay, let me open. --> What happened to this? --> Okay, so let's say I have get 1 and then I have, I'm having sequence number 1,000 --> and I am sending 100 bytes of data. --> Okay, so, okay. --> What is the sequence number of next packet? --> I am having 1,000 sequence number and then I'm sending 500 bytes of data. --> So what is the sequence number of next packet? --> Sorry? --> 100, okay. --> Let's say, okay, packet 1 has a sequence number 1,000 and then sending 500. --> So the next sequence number, if everything is successful, it's smooth, --> will be start with 1,500. --> So what is that mean? --> Okay, and this means this packet, it already contains bytes 1,000 to 1499. --> So it's like a book, a big book, one page at a time. --> Each page has a number, page 1, page 2, page 3, page 4, page 5. --> So the sequence number, just imagine, what is the sequence number? --> It actually tells the receiver where in the book this page belongs to. --> So I tell the client, I tell the client, --> So please start reading it at page 1,500. --> Do you get what I mean? --> Like a page number. --> So you are sending the data from which page. --> If I have 1,000 pages in this book and passing you this very big book with 1,000 pages, --> I tell you, hey, Tam, please read the book. --> But do you know which page you are going to be read? --> You don't know. --> So I'm telling you, okay, please read from page 1,500. --> But then, okay, so how do you know how many pages that you are going to read? --> So that's why I have the data byte size. --> So this is just imagination to match with the real-world case. --> So just now we mentioned about the acknowledge number. --> I give you one example to help you to try to imagine the real-world case. --> Acknowledge number is how the receiver tells the sender, --> I got everything up to this byte. --> You can send more. --> So for example, if the receiver sends an acknowledge --> with an accurate with the acknowledge number 1,500, --> it means I have received byte 0 until 1,499. --> So please send me byte 1,500 next. --> So it's like saying, thanks, I got everything up to this point. --> Keep going from here. --> So another question, I'll give you one example. --> So I'll give you another example. --> Let's say sequence number equal to 1,000. --> This packet starts as byte 1,000, right? --> Because sequence number is 1,000, correct? --> And length equal to 500 bytes. --> So it means it's carrying data size is 500 bytes. --> Acknowledge number is equal to 1,500. --> That means the other side already has received everything up to byte 1,499. --> OK. --> It's a bit confusing, but never mind. --> I will go deeper in tomorrow's session by using different lab examples, --> especially for the sequence number, acknowledge number. --> So that's why in the first lesson that I introduced yesterday, --> I like to add two more columns, especially sequence and acknowledge number. --> Then you will see, hey, what happened? --> Acknowledge number is 1,500. --> But then, what happened to the next packet? --> Maybe acknowledge number is not the right and not accurate, --> or sequence number is not accurate. --> Jump from here to there, there to here. --> So I found something wrong. --> Just for your heads up. --> So the last one in this morning's session. --> Let's continue to the next one, the last one. --> I think the last one before we go into a very big lab exercise. --> From here, I want to tell you, apart from we are observing the time sequence, --> which means the server from the server side, --> we can also look into the round trip. --> And the short form is RTT. --> And what does that mean, RTT? --> Okay, I tried to put here, it's for your better reference. --> RTT means it's a time in text for a packet to travel from the sender to receiver and back again. --> So typically, it's measured using the TCP acknowledgements. --> It's a round trip, go and back. --> So it's a key indicator of a network lesson. --> From here, I already captured the screenshot --> for this PreLab slow network PCAP file. --> So we know that this is a TCP stream between the client 172 to the server. --> So RTT actually is calculating in milliseconds. --> You can see in the Y axis using milliseconds instead of seconds. --> But the time in the X axis is using seconds in the unit. --> So what is the key observation and analysis in this round trip time graph? --> What have you found? --> Again, this is from zero. --> Let me open the workshop. --> Okay, so from this perspective, the Y-axis perspective. --> Let me think how to introduce in a better way. --> Okay, so we do have the sharp RTT spikes. --> Sharp RTT spikes is about here. --> It's around here. --> 60 milliseconds, right? --> So then how long for the time duration? --> It's about 20 seconds. --> So the spike is around 60 milliseconds for the round trip, --> but for the duration is about 22 seconds. --> But then it's a big jump from around 22 seconds. --> It's a steep drop, drop to here. --> So it may suggest to, again, retransmission, --> writing longer for the acknowledgement, --> extract from server or packet loss or server processing delay. --> So it's unstable RTT between 22. --> Okay, from here I can see 22.5. --> Okay, 22, 21. --> So it's around 22.5. --> Seconds until 23.5, I think. --> It's about here. --> It's very unstable because we can see --> this graph is showing inconsistent slope. --> Sharp up and down, up and down, right? --> So it indicates unstable or congested network behavior. --> Okay, so again, after the initial peak, --> this is the initial peak, RTT drops significantly. --> So it may due to TCP slow, --> start competing and traffic stabilizing. --> Okay, or act delay or bursty communication. --> Control between 20, I think here. --> From 20.5 seconds until 21.5 seconds. --> Okay, like this is a small spike. --> We can see small spike and this is the most top spike. --> Okay, so from the instability and the small spike --> and the high spike and the sharp drop, --> up and down. --> So we can conclude that the traffic is not stable --> and it might have network congestion issue. --> It might have network slowness --> or jitter in parts of the communication --> because it's not consistently stable. --> Okay, especially around the 22 seconds in here. --> This one, okay. --> Let us back to, okay, see. --> During the 22 seconds around here, --> you can see a lot of packets are sending out, --> especially a continuation frag. --> But after 24.2 seconds, it stopped. --> And what is happening in here? --> So the client send to server but server never respond --> until 69 seconds, I can see TCP keep alive. --> Okay, after a few milliseconds, --> server responded. --> I'm still alive. --> But then it's nothing after 69 seconds. --> Okay, so client ask the server again. --> Are you still alive? --> Are you still alive? --> And then after a few milliseconds, --> the server responded. --> Yes, I'm keep alive. --> After 114 seconds, it's nothing. --> Okay, but then 156, you can see the red flag happening. --> So what is happening? --> I will go in deeper in tomorrow's session. --> Okay, is that okay? --> I have few laps to indicate. --> And I will try to get more involvement in the lab exercise. --> I'm not going to just explain in the theory --> and showing you the, okay, let me show you. --> Yeah, the summary, the key observation. --> But instead, I will try to get involved --> in the analysis and investigation task. --> Okay, so that's all for this morning session. --> I will, okay, hold on, let me check the time. --> Let me pause the recording first. --> So let us back at 1 and 10, 1 and 10 p.m. --> Okay, at least you have one more than one hour --> because otherwise it's too rush for you for lunchtime. --> Okay, and then I hope you can enjoy your lunch break --> and then you have some takeaway, --> even though it's a bit more deeper, --> it's more technical compared with the previous yesterday session --> because yesterday is just a basic knowledge. --> But today is going more deeper --> and tomorrow we're going more deeper and deeper. --> But I hope this afternoon session after the lab, --> you can learn more, right? --> Okay, see you later after lunch. --> All right, bye. --> I'm waiting. --> I didn't count. --> Oh no, how many times did you go? --> One, two, three, four, five, six, seven, eight, nine, ten. --> So you don't count the hospital, you don't count the room. --> You count this room. --> This is four times, right? --> Four times or five times? --> It's four times, four times, four times, eight times. --> What did you say today? --> I just said I was going to the hospital. --> I was going to the hospital. --> I was going to the hospital. --> What does that mean, you're going to the hospital for a month? --> I'm going to the hospital. --> I'm going to the hospital. --> I'm going to the hospital. --> Did he tell you to continue taking the medicine? --> I'm going to the hospital. --> Is there tea here? --> I didn't ask. --> I didn't ask. --> There seems to be no tea. --> Do you want to have some rice? --> No, no. --> I don't need rice. --> There's too much. --> I know I can put it on your shirt --> You can put it on or not --> This shirt --> I don't know --> I don't know --> This shirt --> I don't know --> I don't know --> This shirt is 3.9 --> I don't know --> This shirt is just 3.9 --> I only know this shirt --> You don't need to change it. You can sleep on your own. --> Oh, I can't stand it anymore. --> You like to talk. --> You want to sit on the table? --> You can go. You have time to chat. --> I want to kiss you. --> What are you going to use? --> Then talk like this. --> What are you doing here? --> What are you doing? --> I am... --> I am going to use the cooking oil. --> You can use it for fried rice. --> It's expensive. --> You don't want to use it? --> You don't want to use it? --> You don't want to use it? --> Wait a minute. --> I am thinking about something. --> I am thinking about something. --> You can give it to him. --> I am thinking about something. --> I am thinking about something. --> I am thinking about something. --> I am going to continue my class. --> After tomorrow, I am going to eat fried rice. --> The sauce is weird. What do you add? --> I add chili oil. --> I am going to add chili oil. --> I am going to add chili oil. --> I am going to add chili oil. --> I am going to add chili oil. --> I am going to add chili oil. --> I am going to add chili oil. --> My water bottle. --> I don't know how to say it in Chinese, but I think it's a good way to say it in Chinese. --> I think it's a good way to say it in Chinese, but I think it's a good way to say it in Chinese. --> I don't know how to say it in Chinese, but I think it's a good way to say it in Chinese. --> I don't know how to say it in Chinese, but I think it's a good way to say it in Chinese. --> I don't know how to say it in Chinese, but I think it's a good way to say it in Chinese. --> I don't know how to say it in Chinese, but I think it's a good way to say it in Chinese. --> I don't know how to say it in Chinese, but I think it's a good way to say it in Chinese. --> I don't know how to say it in Chinese, but I think it's a good way to say it in Chinese. --> I don't know how to say it in Chinese, but I think it's a good way to say it in Chinese. --> I don't know how to say it in Chinese. --> I don't know how to say it in Chinese, but I think it's a good way to say it in Chinese. --> I don't know how to say it in Chinese. --> I don't know how to say it in Chinese, but I think it's a good way to say it in Chinese. --> I don't know how to say it in Chinese. --> I don't know how to say it in Chinese. --> Thank you. --> Thank you. --> Thank you. --> Thank you. --> I hope you enjoy your lunch. --> I hope you enjoy your lunch. --> I hope you enjoy your lunch. --> I stayed there for two months just to experience the Thailand's life. --> I like the environment there and the culture. --> I like the people there. --> I like the people there. --> I like the people there. --> I like the people there. --> I like the people there. --> I like the people there.