What are Ethernet, IP and TCP Headers in Wireshark Captures

What are Ethernet, IP and TCP Headers in Wireshark Captures

1 Slide11

What are Ethernet, IP and TCP Headers in Wireshark Captures

If I could go back in time when I was a n00b kid wanting to go from zero to a million in networking, the one thing I would change would be spending about 6 months on the fundamentals of networking headers and framing before ever touching a single peice of vendor gear. Ethernet, IP and Transport headers (L2-L4) are the past present and future of networking. Protocols will come and go, Ethernet and IP will undoubtedly be with us for the rest of our careers. I know a lot of good engineers, Ops and architects that have learned and forgotten fundamental details five times over, me included as we fill our heads with timers of IGPs and framing encapsulations of data center interconnects.

I tend to try and go back and refresh the basics on the wikis as much as possible. Example, 802.1Q encapsulation is not actually encapsulating the original frame but inserting a 32-bit field with the TPID, VID etc.

Layered architectures are great (in theory :-) but it requires understanding how they interact with one another. I think the encapsulation of the layers can be tough to wrap ones head around as they are entering the field. Once they do they become rock stars, as the beauty of decoupling the layers allow for comprehension of enormous scale.

When working with interns at work we tend to start by breaking out Wireshark capture. This doesn’t necessarily always help, as that can be even more confusing than looking at abstracted theoretical layers for a greenhorn. I tend to break a Wireshark capture down and try to correlate that to the three most relevant layers and their headers L2-L4.

  1. Ethernet II – Layer 2
  2. IP Header – Layer 3
  3. TCP Header -Layer 4. I left out UDP since connectionless headers are quite simpler, e.g. Source Port, Destination Port, Length and Checksum.

Wireshark Example Tutorial

Figure 1. An example of a Wireshark capture.

Figure 2. The summary before the protocols in a Wireshark packet. Information about the packet characteristic.

Ethernet II Header and Capture

Figure 3. Ethernet II (Layer 2) header along with the Wireshark

IP Header Wireshark

Figure 4. IP Header (Layer-3)

IP Header
  • Version IPv4, IPv6 etc.
  • IP Header Length (number of 32 -bit words forming the header, usually five)
  • Type of Service (ToS), now known as Differentiated Services Code Point (DSCP) (usually set to 0, but may indicate particular Quality of Service needs from the network, the DSCP defines the way routers should queue packets while they are waiting to be forwarded).
  • Size of Datagram (in bytes, this is the combined length of the header and the data)
  • Identification ( 16-bit number which together with the source address uniquely identifies this packet – used during reassembly of fragmented datagrams)
  • Flags (a sequence of three flags (one of the 4 bits is unused) used to control whether routers are allowed to fragment a packet (i.e. the Don’t Fragment, DF, flag), and to indicate the parts of a packet to the receiver)
  • Fragmentation Offset (a byte count from the start of the original sent packet, set by any router which performs IP router fragmentation)
  • Time To Live (Number of hops /links which the packet may be routed over, decremented by most routers – used to prevent accidental routing loops)
  • Protocol (Service Access Point (SAP) which indicates the type of transport packet being carried (e.g. 1 = ICMP; 2= IGMP; 6 = TCP; 17= UDP).
  • Header Checksum (A 1′s complement checksum inserted by the sender and updated whenever the packet header is modified by a router – Used to detect processing errors introduced into the packet inside a router or bridge where the packet is not protected by a link layer cyclic redundancy check. Packets with an invalid checksum are discarded by all nodes in an IP network)
  • Source Address (the IP address of the original sender of the packet)
  • Destination Address (the IP address of the final destination of the packet)
  • Options (not normally used, but, when used, the IP header length will be greater than five 32-bit words to indicate the size of the options field)
TCP Header

Figure 5. TCP headers.

TCP IP Header Explained

  • Source port (16 bits) – identifies the sending port
  • Destination port (16 bits) – identifies the receiving port
  • Sequence number (32 bits) – has a dual role:
  • If the SYN flag is set (1), then this is the initial sequence number. The sequence number of the actual first data byte and the acknowledged number in the corresponding ACK are then this sequence number plus 1.
  • If the SYN flag is clear (0), then this is the accumulated sequence number of the first data byte of this packet for the current session.
  • Acknowledgment number (32 bits) – if the ACK flag is set then the value of this field is the next sequence number that the receiver is expecting. This acknowledges receipt of all prior bytes (if any). The first ACK sent by each end acknowledges the other end’s initial sequence number itself, but no data.
  • Data offset (4 bits) – specifies the size of the TCP header in 32-bit words. The minimum size header is 5 words and the maximum is 15 words thus giving the minimum size of 20 bytes and maximum of 60 bytes, allowing for up to 40 bytes of options in the header. This field gets its name from the fact that it is also the offset from the start of the TCP segment to the actual data.
  • Reserved (3 bits) – for future use and should be set to zero
  • Flags (9 bits) (aka Control bits) – contains 9 1-bit flags
  • NS (1 bit) – ECN-nonce concealment protection (added to header by RFC 3540).
  • CWR (1 bit) – Congestion Window Reduced (CWR) flag is set by the sending host to indicate that it received a TCP segment with the ECE flag set and had responded in congestion control mechanism (added to header by RFC 3168).
  • ECE (1 bit) – ECN-Echo indicates
  • If the SYN flag is set (1), that the TCP peer is ECN capable.
  • If the SYN flag is clear (0), that a packet with Congestion Experienced flag in IP header set is received during normal transmission (added to header by RFC 3168).
  • URG (1 bit) – indicates that the Urgent pointer field is significant
  • ACK (1 bit) – indicates that the Acknowledgment field is significant. All packets after the initial SYN packet sent by the client should have this flag set.
  • PSH (1 bit) – Push function. Asks to push the buffered data to the receiving application.
  • RST (1 bit) – Reset the connection
  • SYN (1 bit) – Synchronize sequence numbers. Only the first packet sent from each end should have this flag set. Some other flags change meaning based on this flag, and some are only valid for when it is set, and others when it is clear.
  • FIN (1 bit) – No more data from sender
  • Window size (16 bits) – the size of the receive window, which specifies the number of bytes (beyond the sequence number in the acknowledgment field) that the sender of this segment is currently willing to receive (see Flow control and Window Scaling)
  • Checksum (16 bits) – The 16-bit checksum field is used for error-checking of the header and data
  • Urgent pointer (16 bits) – if the URG flag is set, then this 16-bit field is an offset from the sequence number indicating the last urgent data byte.
  • Options (Variable 0-320 bits, divisible by 32) – The length of this field is determined by the data offset field. MSS etc.

If this helps anyone I will do a second post including MPLS encap, 802.1Q trunking, IPv6, ICMP and ARP on another post.

Part 2 rolls the headers together in the stack.


Thanks for stopping by.

  1. joejoe06-24-2012

    It is really very well done.Over time we forget all basic fundamental details. It would be nice to see one on MPLS encap, 802.1Q trunking, IPv6, ICMP and ARP too.

    appreciate it.
    thank you

    • Brent SalisburyBrent Salisbury06-24-2012

      Hi Joe, Thanks for the nice comment. I agree but hey its pretty complicated stuff even if we have learned it a few times over again. Have totally been meaning to do it for MPLS packets. Great point on ARP and ICMP. Especially the different types and codes. I really want to do a write up on PMTUD. It is pretty amazing it all works as well as it does. I just read this in an article “Your average 5-minute YouTube video is about 10 million bits” Seriously 10million bursts of electricity all being managed and run up and down the abstraction stack. woah! Throw your twitter handle on here if you have one so i can follow.

  2. ooosssooosss08-29-2012

    Excellent work.
    Thanksssss alot

  3. PaulPaul01-21-2013

    loving this site, currently trying to build openstack cloud for my Fyp and came across this place, great article on networking fundamentals, Cheers

  4. Brent SalisburyBrent Salisbury02-21-2013

    Thanks Paul, appreciate it!

  5. Simply want to say your article is as amazing. The clearness for your publish is simply excellent and
    that i can suppose you’re a professional in this subject. Well along with your permission allow me to snatch your RSS feed to stay updated with drawing close post. Thank you 1,000,000 and please carry on the enjoyable work.

  6. Dustin BurnsDustin Burns03-29-2013

    ” a n00b kid wanting to go from zero to a million in networking”, how nice of you to mention me in this post :). I totally agree with the point you make here. Engineers like myself tend to be distracted by all the new tech that’s out there, and want to find the quickest easiest way to understand it. Take the scenic route, and develop your foundation. Build upon that, and don’t forget to go back to fix the “cracks/leaks”.

  7. Brent SalisburyBrent Salisbury04-01-2013

    Thanks Dustin! I tend to go back and review the fundamentals every quarter, mainly becuase I have memory leakage :) The idea that network evolution will obsolete fundamentals is silliness. The fundamentals will be more important then ever.

    Folks should check out Dustin’s blog at http://bitchaser.wordpress.com


  8. MaynardMaynard03-05-2014

    Today, while I was at work, my cousin stole my iPad and tested to see if it can survive a twenty five foot drop, just so she can be a youtube
    sensation. My apple ipad is now broken and she has 83 views.
    I know this is totally off topic but I had to share it
    with someone!

Leave a Reply