Labels: packet analysis , Wireshark

Packet Analysis 101 - Wireshark's Packet Details

"The time has come," the Walrus said,
"To talk of many things:
Of bits-and bytes-and frame headers--
Of trace routes-and pings...

You've already seen how to use Wireshark to take a packet capture, how to set capture filters, and how to set display filters.  In this post, we're going to talk about Wireshark's Packet Details View.

Packet Details

What's nice about Wireshark's Packet Details View is that it parses out the packet in easy to read sections that map to the OSI model:


Since the packet details are structured according to layer-specific information, I can quickly expand a collapsed section related to the target of my search.  Pro-tip: this is where understanding networking and application behavior is really helpful.  Don't worry if you're not familiar, because this is also what helps you learn how the packets are placed onto the wire.  Let's dive into this one layer at a time.

Packet Frame Header

Some important things to note first before we discuss too many details.  When you expand a "layer" in the Packet Details View, anything in brackets is something not found in the actual packet, but is inserted by Wireshark during the loading of the packet capture.  Fun stuff to note for later includes the time delta and coloring rule.

What's funny about this part of the packet view is that if you take away the bracketed lines, there's not much info left!  Interface ID, Encapsulation Type, Arrival Time, Epoch Time, Frame Number, Frame Length, and Capture Length.  I'm still learning, of course, but what I've found is the most important is the Frame Number.  When troubleshooting a network communication issue, it's extremely helpful to guide someone else through the packet capture using the Frame Number as a point of reference.

Ethernet Header (OSI Layer 2 - Datalink)

With or without expanding the Ethernet header, we can see the source MAC address and destination MAC address.  This is handy when troubleshooting an outbound packet, because you can see where the packet was destined to reach.  Typically, this destination MAC belongs to the default gateway, but it depends on the network topology.

What's nice in troubleshooting as well is that the first six hexadecimal digits are parsed by Wireshark to display the user-friendly NIC identifier, commonly referred to as the manufacturer's registered identification number.  If you know your device, then you can easily recognize the packets sent and received by your device based on MAC.  Why is this important?  Load-balanced clusters that share a virtual IP address.

IP Header (Layer 3 - Network)

In the IP header, we see the source and destination IP addresses.  When dealing with packets on WAN links, sometimes people utilize the DiffServ Code Point value (DSCP) as a Quality of Service mechanism to classify packets into prioritized buckets.  Higher-priority packet buckets get processed first.

TCP Header (Layer 4 - Transport)

Focusing on the highlighted line in blue, we quickly see the source port and destination port.  From those numbers, it's typically easy to recognize which is the sender and receiver.  When a host sends a packet to another host, the port chosen on the source is a randomized ephemeral port higher than port 1024.  The destination host in this case is a webserver, which makes sense since we're looking at an HTTP packet, and the destination port is 80 (the normal server port over which HTTP connections are established).

In the exploded view, we see the Flags section which indicates certain information related to the nature of the connection.  For instance, the Push flag is set, which is an indicator that the packet should be processed up to Layer 7 because the source is sending data to the destination.  In this packet, that data is the URL in the GET request.  It's at this part of the packet attacks like the Christmas Tree attack are initiated against a webserver.  This video explains it perfectly:

HTTP (Layer 7 - Application)

Expanding the HTTP layer, we see the formation of the GET request.  Bonus points on my imaginary scoreboard if anyone can let me know in the comments whether the request is explicit or transparent.  In the GET request, I can see the HTTP protocol version used (1.1) and the path of the request.  The path in this packet is "/", meaning it was a request for the root web directory.

The Host Header instructs the server to send the root web directory back for www.msn.com.  Can anyone guess why the Host Header is important?  Think about it for a second, and then you can check your answer.

Below the Host Header, we can see other HTTP Request Headers the browser of the source host sent to the webserver.  The ones to discuss are User-Agent, DNT, Accept, Accept-Encoding, and Accept-Language, but head on over to my HTTP Headers post if you're interested.  In this here post, we're focusing on the packets!

At the very bottom of the HTTP layer of the packet, you can see some helpful bracketed information Wireshark parsed out for us.  We can see the Full request URI, which means the request was observed as http://www.msn.com.  And we see that the webserver responds to this packet [Frame 294, see above] in Frame 389.  That allows you to scroll through the packet capture to Frame 389 to see what the server sent back.

Conclusion