 and Wireshark presents by default three different areas to view the packets that were captured. So there's the top area which is a list of packets, one line per packet. Everything captured is listed here. Then when you select one, the bottom two areas, this area shows the details of that one selected packet in some nice human friendly form. You can zoom in on parts and look at header fields. And down the bottom, it shows the details of that packet in the computer friendly form of, in this case, hexadecimal. Packets are just a sequence of bits. It's just that some of those bits have special meaning. Well, instead of showing the bits, we could do the bits view. If you right-click in this bottom area, I can get the bits view. If you want to really look at the binary form of the packet, you can do that. But by default, it shows a hex view, a bit shorter. This is the raw form of the packet. The middle part is the interpretation from Wireshark's perspective of what that raw form means. And that's the thing that we mainly look at, the middle part. Note down the bottom, it may be hard to see on the screen, but right down the bottom in the status bar, when you select something in the middle part, it shows you how many bytes. When I select my frame, it shows down the bottom 214 bytes. I select Ethernet, 14 bytes. IP, 20 bytes. Note the status bar shows you something about size. That's useful when we want to observe how big our packets are. First, let's look at the packet list. Packets are ordered. I captured 700 packets. They're given numbers. And the first one, we say, was captured at time zero. And then each subsequent packet, some time later, measured in seconds. So the second packet in mine was six microseconds after the first one. So we have the time. That's measured in seconds relative to the very first one. Who sent it? Who received it? Source of destination. This is the application or highest layer protocol used, so that tells us about what was happening, what this packet's related to, secure shell, the length of that packet, and some summary information. This first packet sent by me, computer one, sent to who? Stand up if you receive the first packet on my screen. Don't be shy. Anyone? Someone standing up or just leaving? Is anyone sitting at computer 27? We have a ghost there. Or at least put your hand up if you don't want to stand up. Okay, so this packet on my screen, you can sit down now. This was sent by my computer to computer 27. I know by the IP addresses. Using secure shell, why? Note that everyone's logged into my computer. At the start, you SSH into my computer. So there are many packets going to and from my computer. Computer 27, 26, 12, 3. So this is all of your computers when you've logged into mine. Let's find my web page request. Because when I captured, I accessed a website. I hope I've captured that packet. So the filter is very useful. Of those 700 packets, I don't want to have to browse through and find the ones of interest. Take some time. There are a lot of packets being sent in the background. Let's find the ones of interest using a filter. And on the slides, I give some example filters. You can try some of them. You'll work out the best ones for you. I'm going to filter and try and find HTTP. And IP address equals me. Show me all the HTTP messages where the IP address, source or destination is my computer. And I apply that filter. And now I get just two packets. And hopefully you can see that the first one sent by me to 10.10.6.11. Going back to WGet. 10.10.6.11 is the IP address for the ICT server. The first one was sent from me to the web server for ICT. And the second one is sent from the web server back to me. That's what I observe here. Using HTTP. And the summary was the first one was me, my browser, saying get the page identified by forward slash. The response was the server saying, here it is, everything's okay. And if you look in that response, you'll see that just briefly, and you'll have a chance to do this yourself the rest of the lab today. So I'll just go through quickly. That response message was 1,418 bytes. It contained an ethernet header. Inside that contains some source and destination addresses, some hardware addresses. An IP header. Inside that, source addresses and other fields. Fields of the IP header. Uses TCP. HTTP uses TCP. Port number 80 from the web server to my web browser. In this case it says there's two reassembled segments. The reason was the web page was too big to fit into one segment. It was split across two. And they were joined together. And the HTTP header showing some information about the web server response and maybe the thing of interest, the line-based text data is the web page. So the web page sent from ICT server was included in this response and that allowed my WGEP program to save it in a file. So your objectives today are to learn how to capture with TCP dump. Not so hard, you've just done it. And then learn how to find information in Wireshark. So over the rest of the course we will use Wireshark a number of times and you say capture this and then answer some questions. So today's getting some initial experience with using Wireshark. That is what all these columns mean, how to interpret the packet details, how to do filters are some of the things I want you to learn today. And to learn there are some tasks. So in the following three tasks what you need to do really is capture with TCP dump, use some application, stop the capture, open in Wireshark and then answer some questions from what you observe in Wireshark. And I'll ask you to draw some pictures as well. So make sure you have some paper and pen or pencil to draw some pictures soon. You'll see some examples on the next two slides but I'll let you do the capture first before I explain the message sequence diagram and packet diagram. But I think you've seen them before, so not too hard. So to the first task let's use Netcat, which you know how to use, with your friend, start a capture, start TCP dump, use Netcat, serve a client, send some hello messages to each other, stop your capture, and find the packets which were sent in Wireshark. And to make it... Well, yeah, do it first in the normal Netcat mode which will actually use TCP and if you can do that then you can try it again but use Netcat in UDP mode. So the first task, start TCP dump, use Netcat with your friend, both of you can use TCP dump in one terminal, use Netcat in another terminal, once you've sent some messages to each other stop TCP dump, open in Wireshark, and just find the packets related to Netcat. You need to search through and maybe find a filter.