Use Wireshark to inspect packets on your network

Scott Reeves illustrates how you can use Wireshark to inspect packets, looking specifically at various points in the OSI layer, to troubleshoot network issues.

I've been using Wireshark in a number of my posts to show aspects of network performance and to illustrate areas of TCP/IP such as the three way TCP handshake. This week, I thought I'd delve a little more into Wireshark itself and illustrate how the OSI layer works.

Two previous posts have shown the TCP three-way handshake (see, for example, my previous post "Using jperf and Wireshark for troubleshooting network issues"), so I will omit covering it in this post. What I will do is draw attention to the way you can look inside a packet captured using Wireshark. For this example, I used a capture of a network session run using a jperf client and a server. Figure A is a sample from this capture.

Figure A

Click to view larger versions of images.
Looking at Figure A, you can see that the first line shows a summary of the frame. The other lines show the data link layer, the network layer, the transport layer, and finally, the actual data contained within the frame. I will step through each line in order.

One note before beginning: Wireshark will highlight the bytes in hex in the bottom pane (as shown in Figure A). You can change this to binary if desired.

Data Link

Figure B

Moving to the Ethernet layer (shown in Figure B), we can see that it is pretty simple. It contains a destination address and a source address. The data link layer is relatively simple in that it is only concerned with getting a frame to the next adjacent node on the physical medium. The main point of interest is the Organizational Unique Identifier (OUI), which takes up the first three bytes of an Ethernet address. The IEEE assigns the OUI to manufacturers of Ethernet equipment. If you want to take a look at assigned OUIs, the list is maintained at

Wireshark makes it easy for you to check on the manufacturer of a card; you can highlight the field (as shown in Figure B) and extract the OUI. You can then plug the number into the website,, and obtain the manufacturer.


The Ethernet layer is concerned with node to node. The IP layer is concerned with moving between networks, hence the original meaning of the term internetwork, from whence Internet was derived. Highlighting the network layer shows more details. From Figure C, we can see the source and destination IP addresses as well as the IP header length (20 bytes in this case).

Figure C

We can also see the Differentiated Services (DiffServ) area. This would be where extra information relating to the packet's type of service goes. For most packets on a LAN this is set to zero, which means best effort. There are several other levels, such as Expedited Forwarding, which generally has low loss, low delay, and low jitter. Diff Serv levels can be used when looking to implement a Quality of Service on IP networks.


The transport layer is where applications communicate via the use of ports. Looking at the capture shown in Figure D, we can see that the source port is 40519, while the destination port is 5001.

Figure D

Other areas of interest are the header length (32 bytes in this case) and the sequence number.  The sequence number generally will change for each packet.


The final part of the capture is the data part; this is shown in Figure E. Here you will see what data is being sent over the medium. This is where you will find applications such as ssh are very important: using ssh means that a login name and password are encrypted.  In contrast, rsh and rlogin are not encrypted; data is sent in clear text, meaning that you can capture a packet and read the login name and/or password from the data section of the captured packet.

Figure E


The size of the data part of the frame is 1448 bytes in this case. There is some overhead due to the headers used by TCP, IP and Ethernet. From Figure E, we can see that the actual frame size is 1514 bytes, whereas the size of the data is 1448 bytes. The overhead in this case is 64 bytes. Of this, 12 bytes is Ethernet, 20 bytes is IP and 32 bytes is TCP.

Wireshark offers many other features, other than the ability to inspect frames. This post touches on how to look at various points in the OSI layers, which can act as an aid in troubleshooting network problems. It can also help you to understand what sort of traffic is going over the network.


Scott Reeves has worked for Hewlett Packard on HP-UX servers and SANs, and has worked in similar areas in the past at IBM. Currently he works as an independent IT consultant, specializing in Wi-Fi networks and SANs.


My comment is on the .enc file extension when you install Wireshark for 32-bit OS. It shows up everywhere in your file system, the registry key is created for the software to work and all the other usual installation steps take place. What I don't get is how the .enc file extension was found all over the place, I know its the "capture file". I went straight to to search their FAQ and help database but to no avail. Does anyone know how or why this happens. I had been using Wireshark for some time (not in the "workplace" as in monitoring; what comes in/out your network) but for testing and experimenting. The fact that you can apply so many filters for more specific packets and protocols or ports (from avaya to zigbee) is really what I thought was a highlight of the software. I don't get the chance to use the computer much nowadays but still try to keep updated. I tryed Snort, but that for me was a little more cumbersome having to write scripts and then run everytime I wanted to use the application, in fact if it had come with a GUI aside from the CLI version, I say it would recieve a little more attention; over all it is still pretty useful.


One of the more useful pieces of info in the Frame layer is the system time stamp. This relates to the system time of the device doing the capturing. It is necessary when trying to correlate network packets with other problems such as session failures. You may need to adjust for the time zone but this helps you find a call in a large file of CDRs for instance. Or at least the proper file to search for the Call-ID.

Editor's Picks