0

Data

Some Cloudshark captures show a "Trailer" for the vLAN and some do not.

Evidence

Captures

  1. With extra 4 bytes.
  2. Without extra 4 bytes.

Question

Why do some and not all VLAN Wireshark captures include data after the IPv4 payload?

Klik
  • 101
  • 3

2 Answers2

0

How do I accurately predict the size of IPv4 packets with vLAN tags from reading the header?

IPv4 packets do not have VLAN tags in the header. Only the ethernet frame (layer-2) header will have VLAN tags. An IPv4 packet (layer-3) is the payload of the frame, and the IPv4 packet header will not know anything about what is in the frame header. These are two separate layers in the network, and IPv4 can be carried by any number of layer-2 protocols, while remaining blissfully ignorant of the layer-2 protocol used.

If you want to know the size of the IPv4 packet, you can look in the IPv4 packet header for the Total Length field (third and fourth octets of the IPv4 header).

Ron Maupin
  • 3,243
  • 1
  • 12
  • 20
  • Thank you for clarifying. What I have found though is that the length, as indicated by the IPv4 header, is not an indication of where the end of the packet is. If there is no VLAN, then I can assume the FCS has been stripped and I can judge where the end of the packet is by the length field in the IPv4 header, but if there is a VLAN tag, then sometimes there is a 4 byte trailer on the end. If you look at the two examples I posted, one of them ends after the IPv4 payload, and the other has an additional 4 bytes. Both are VLAN. How can I predict this? – Klik Jul 14 '16 at 16:56
  • Whether or not a VLAN tag is used has no bearing on the size of the IPv4 packet. A VLAN tag will increase the ethernet frame by four bytes, but it does not change the IPv4 packet at all. The IPv4 total length is the total size of the IPv4 packet. Remember that ethernet must pad the payload under certain circumstances, but that is not included in the IPv4 packet size. The frame payload may be larger then the IPv4 packet size. Look at wiki.wireshark.org/Ethernet – Ron Maupin Jul 14 '16 at 18:13
  • I need to find the size of the entire frame. Because I'm doing this all in hardware, I need to know how much data will be written to the buffer when I have the first 6 64 bit words of the frame. This is because I need to predict where to place the pointers for my buffer. I cannot wait until the end of the packet; the most efficient way to do this is to understand the standards (which I'm struggling with) so I can make accurate predictions. After finding the IPv4 length field, I am not sure whether the packet will end after the IPv4 payload, or whether there will be an additional 4 bytes. – Klik Jul 14 '16 at 18:29
  • There may be additional payload padding to bring the frame length to the minimum 64 bytes. The actual frame size generally includes the FCS, but not the preamble. Without a VLAN tag the maximum is 1518 bytes (14 header bytes, 1500 payload bytes, and 4 FCS bytes). A VLAN tag adds 4 bytes to the frame header. All frames have an FCS. Whether or not that gets reported to you by an application is up to the application. Many PC NICs will strip the VLAN tag since VLAN are only used on trunks, not on access ports to hosts. Some severs can connect with trunks. – Ron Maupin Jul 14 '16 at 18:41
  • The FCS is what interests me. It is always after the IPv4 payload. Why does one of the two links I've listed in my question, have an FCS? Both are wireshark captures, though I don't know the conditions with which they were captured. I'm told that the FCS will be stripped from the MAC (I receive the signal immediately after the MAC), but I don't know why some wireshark captures include these trailling 4 bytes? I understand there are 4 bytes added in the Ethernet frame header, but sometimes there are also 4 bytes tacked on the end. Please look at the two captures and explain the difference. – Klik Jul 14 '16 at 18:52
  • The FCS has nothing to do with IPv4, nor is it in the frame payload. The FCS is part of the ethernet frame. IPv4 has its own CRC that has nothing to do with the ethernet frame. Don't confuse the two protocols. The addition to the payload may be padding due to the size of the IPv4 packet. – Ron Maupin Jul 14 '16 at 18:55
  • Could you please look at the wireshark capture? The packet is 78 bytes long and so I'm sure it is not padding. – Klik Jul 14 '16 at 18:59
  • Unless I misunderstood what you said about packets being padded to 64 bytes. Perhaps a better question is, when am I going to see an Ethernet packet that has additional bytes after the IPv4 payload? (for packets larger than 64 bytes) – Klik Jul 14 '16 at 19:04
  • The packet size is 56 bytes, the frame size is 78 bytes. You keep confusing ethernet and IPv4 terminology. These are two separate protocols at different layers, and each cares nothing about the other. The 78 byte frame size minus the 56 byte payload (packet size) is 22 bytes, and that is 14 bytes (normal header) plus 4 bytes (VLAN tag) for the header, and four bytes for the FCS. – Ron Maupin Jul 14 '16 at 19:14
  • Yes, but then why do they not have the extra 4 bytes here? I don't see the FCS here. https://www.cloudshark.org/captures/c963ae5aa12a?filter=frame%20and%20eth%20and%20vlan%20and%20vlan%20and%20ip%20and%20icmp – Klik Jul 14 '16 at 19:16
  • As i explained above, all ethernet frames have the FCS. Whether or not the application you are using to capture reports this is up to the application or the NIC. The FCS existed on the wire. If your captures are on different PCs, it could be the NIC or the driver. – Ron Maupin Jul 14 '16 at 19:24
  • It was my understanding that the FCS should not make it to the application because it would be stripped off by the MAC. – Klik Jul 14 '16 at 19:25
  • The MAC is an address in the frame header. I'm talking about the capture application, which taps the network stack long before it goes to an application. The final application will never see the frame, IPv4, or TCP/UDP headers, only the ultimate payload of the layer-4 datagrams. – Ron Maupin Jul 14 '16 at 19:28
  • Then I can completely ignore any bytes after the IPv4 payload. That is what I will do and what I'm actually concerned with. Though I don't understand why Wireshark sees these additional 4 bytes in some circumstances. Thank you for correcting my terminology. I feel guilty for taking so much time. Cheers. – Klik Jul 14 '16 at 19:45
  • Just in case you are confused: What ethernet (layer-2) gets is the whole frame. It passes only the payload up to the layer-3 protocol (IPv4 in this case), and layer-3 never sees or cares about the frame. If the IPv4 packet payload is ICMP, IPv4 uses it, otherwise it send the packet payload to the correct layer-4 protocol (TCP, UDP, etc.), and layer-4 never sees or cares about the packet. The layer-4 protocol will assemble the datagram payload (raw application data), and it will pass that up to the application. The application never sees or cares about any headers lower in the network stack. – Ron Maupin Jul 14 '16 at 20:04
0

See https://wiki.wireshark.org/Ethernet and https://wiki.wireshark.org/VLAN

If the type/length field is:

  • 0 - 1500: length field (IEEE 802.3 and/or 802.2)
  • 0x0800: IP(v4), Internet Protocol version 4
  • 0x0806: ARP, Address Resolution Protocol
  • 0x8100: IEEE 802.1Q frame
  • 0x86dd: IPv6, Internet Protocol version 6

So if the type/length field is 0x8100 then the Ethernet frame includes a VLAN tag following the type/length field. Skip 2 bytes, and look at the next 2 bytes as a type. For IPv4, that will be 0x0800, and your IPv4 data packet starts immediately following that.

longneck
  • 23,082
  • 4
  • 52
  • 86