Where do you see that number 18 ? Does your ping application tell you ? Is it WireShark that explicitly mentions the number 18 ? Or is it what you counted yourself when looking at the hexdump of the packet ?
That number 18 is not a coincidence.
I'll give you 2 clues.
First one:
https://www.google.nl/search?complete=0&ion=0&q=minimum%20framesize%20ethernet
https://en.wikipedia.org/wiki/Ping_(networking_utility)#ICMP_packet
Second one:
64 - 18 - 20 - 8 = ?
Let me know when you get it.
If not, please copy&paste a hexdump of the full Ethernet frame here (including Ethernet-frame-header), so I can see exactly what values are in the headers. Thanks.
====
Edit:
OK, it's not as straightforward as I thought.
But I'm pretty sure that number 18 is because of padding.
Note the difference in terminology here between packet (ip, layer-3) and frame (ethernet, layer-2).
Ethernet frames that are smaller than 64 bytes need to be padded to 64 bytes length.
The padding should be done in the frame *after* the layer-3 packet.
The frame-length should be 64, and never smaller.
You should also know that there are 4 types of Ethernet-encapsulation.
1) Arpa, 2) OSI/LLC, 3) SNAP, and 4) some old Novell crap that I hope nobody uses anymore.
Note that encapsulations 3) and 4) use the 2 bytes after ether-DA and ether-SA as a length field. But Arpa-encapsulation does not use those 2 bytes as length. Arpa-encaps uses it as the type field. (Note, all types are supposed to be larger than 1518, so there's no confusion. IP is type 2048, which is larger than 1518, so no confusion).
So we can conclude that when we use arpa-encaps (like IP does), the frame-length is implicit, not explicit like a field inside the frame-header.
Another note: Ethernet-headers are 18 bytes. That's 14 bytes at the start (6 destaddr, 6 srcaddr, and 2 type/length). And 4 bytes CRC at the end. Wireshark seems to not show the CRC. So that is guaranteed to cause confusion.
Normally icmp-echo-requests have 32 bytes of random data attached to it. This makes the total frame size: 18 ethernet-header + 20 ip-header + 8 icmp-header + 32 icmp-random-data = 78 bytes. My WireShark (windows version. 1.12.2) says 74 bytes. It forgets about the 4 bytes CRC.
When I ping with length zero (e.g. ping -l 0 8.8.8.8) I see a packet going out of size 42. Let's add the 4 bytes CRC that WireShark forgets about. That's 46 bytes then. That means that that frame will have exactly 18 bytes of padding. Wireshark just doesn't show it to us. Inside the ip-header it says "total length = 28". That's 20 bytes ip-header + 8 bytes icmp-header. It all adds up.
Now I look at the return packet. From the router (a Fritzbox by AVM) to my PC. Now WireShark says it sees a 60-byte return frame. Add the 4-bytes CRC, and we are at the magic 64 bytes minimum Ethernet-frame size ! If we look at the total-length field in the ip-header, it says 28 bytes, just as it should.
My conclusion:
WireShark does not see the ethernet-frame padding on outgoing packets.
But it does see the ethernet-frame padding on incoming packets.
Maybe winpcap is to blame ? (Winpcap is the driver that hands-over frames/packets from the windows drivers to WireShark).
Now that I knew where to look, it was easy to find confirmation via Google.
First hit:
http://palewhiteman.blogspot.nl/2010/02/why-wireshark-doesnt-show-padding-on.html
My advice:
1) Look at the total-length field in the ip-header. If that is correct, then you got nothing to worry about.
2) Attach a 3rd device to your network. (A bit hard to do these days, with switches everywhere, and no hubs for sale anymore). Do the WireShark sniffing on the 3rd device. I bet you will now see padding on frames in both directions.
Hope this helps.
This was actually a fun 15 minutes to look into it.
It's been a long time ago since I looked at this. I needed to verify my old memories.
Facebook
Twitter