The usual ping command uses ECHO REQUEST and ECHO REPLY, as you've seen. It does indeed locally keep track of sent time and matches with the incoming reply to determine the round trip time.
TIMESTAMP and TIMESTAMP REPLY are pretty rare, and many sites simply don't answer, as many systems managers believe it to be a security issue, albeit minor. The purpose of the packets is to separate out the the times of the outgoing trip, the far end processing time, and the return trip. ICMP in general is subject to all kinds of manipulations and blockages by intervening routers, so it can be hard to read much into the results if you're using this across a network you don't control.
To send them you can use a utility such as nping from the nmap set of tools. It can be used for all kinds of exotic ping-like tests.
nping --icmp --icmp-type 13 www.google.com
www.google.com won't reply to these, but your packet capture will show them being sent.
Since the ARP packet size is fixed and smaller than a minimum Ethernet payload, padding needs to be used at all times. Wireshark most often doesn't see the FCS that's closing a received frame[1], so it needs to apply some guesswork as to which bytes might be padding. It calls these excess bytes trailer. Padding might show up on sent frames, although these padding bytes aren't usually visible (since they're only added by the NIC/driver).
Basically, it's the same thing - provided Wireshark correctly interprets the frame contents.
[addition for 2nd screenshot]: I'm counting 18 padding bytes which is the exact difference between the ARP packet size (28 bytes) and the minimum Ethernet payload size (46 bytes) - that's padding as required by Ethernet and recognized as such by Wireshark.
The rest is excess data (garbage?) that is trailing the minimum frame, so it's labeled as Trailer. It looks like it starts with the (possibly correct) FCS, followed by some more bytes - potentially metadata misinterpreted by Wireshark, which would also explain the FCS status bad.
You might need to recheck the import options for the dump for Wireshark to make more sense of it.
[1] The real frame end is indicated by the physical layer by just stopping the carrier signal or sending a special symbol (depending on the variant). This isn't visible to the capturing library at any time. The NIC driver just provides a buffer containing bytes, usually also stripped of the FCS.
Best Answer
IEEE 802.3describes structure ofEthernetframes. As it says the minimum frame length is 64 bytes. Every frame less than 64 bytes should be padded with 0 before transmitted on theEthernetlink. This padding is done byEthernetnetwork 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.