I'm using Wireshark for my project. I sent a ping over to Google.com and Wireshark said that the length was 57 bytes(when I received the reply it was 60 bytes long and it contained 6 bits of padding. After I decided to send another packet that Wireshark said was 56 long the reply was 60 bytes long again but the padding contained 8 bits lets say I sent a packet with 42 lengths I received a 60 bytes reply but the padding contained 24 bits. I want to know the reason why.
IEEE 802.3 describes structure of
Ethernet frames. As it says the minimum frame length is 64 bytes. Every frame less than 64 bytes should be padded with 0 before transmitted on the
Ethernet link. This padding is done by
Ethernet network card adapter so you see 60 bytes frame only in received frames. In fact Wireshark capture transmitting frames before they leave the OS and entering the network adapter, i.e before padding process.
Please note that Wireshark omits the 4 last bytes of frame names FCS (Frame Check Sequence) which is used to detect corrupted frames. Thus you see 60 bytes instead of 64 bytes.
what you saw was only the small part of the game, it's true that the minimum frame length for the packet is 64 bytes and it has to be 64 bytes or higher to be considered valid, so what about the encapsulated data that got stripped off by the NIC ? what your computer received was the valid bytes of data but after Decapsulating the encapsulated data the bytes get lower (60 bytes in your case), when you sent the 57,56 bytes of data padding was added and encapsulation was performed which expands the packet bytes and when the packet comes back it is decapsulated and ttl almost to zero so the packets are bound to give unpredictable values, use "tcpdump" to sniff transport layer packets (TCP,UDP) or use snort to be more productive about it.
1The Ethernet frames are de-encapsulated from what? "ttl almost to zero" doesn't make any sense. tcpdump uses the exact same capturing mechanism as Wireshark.– Zac67 ♦Sep 15, 2018 at 7:48