Why Wireshark Doesn't Show Padding on Ethernet Packets

This post will be about a truly esoteric part of the interwebs. I'm going to use my small home network for this discussion. I have a couple desktops hardwired with switches, along with two laptops (an HP and a MacBook) tied in wirelessly. I also have an HP printer that is wired in. The medium, as with most home networks, is Ethernet over 100BaseT. When I use a piece of software that wants to communicate over my network, whether its just to my networked printer sitting next to my desk or to a web server sitting half-way around the world, the software will create a frame of bits. That frame will use an address, called a "medium access control" or "MAC" address, send that frame to the next system in the link. If the address is for something on my network, then the connection is direct. However, if I'm going to send the frame outside my network, to the big Internet, then the MAC address that's used is the MAC address of my little Linksys router. When the frame gets to the router, the router changes the source and destination MAC addresses to those of itself and the server at Comcast (my ISP) that I'm tied into. This is standard Ethernet (802.3) stuff.
But here's a little known (to most non-geeks) fact. My computer only holds onto the MAC address of the systems on the network for about 20 minutes. It keeps these addresses in a file called an "ARP cache". That's a small file that ties IP (Internet Protocol) addresses to MAC addresses. The "ARP cache" is dynamic. It will only keep its contents for 20 minutes, then it's removed. So, what if it's been 20 minutes since the last time I connected over the network? More specifically, what if it's been 20 minutes since I connected to my router? Then the router's MAC address won't be in the "ARP cache". This means it needs some way to find out the router's MAC address. Which is the purpose of ARP, or "address resolution protocol". The purpose of ARP is to allow a system to determine the MAC address of another system given that it knows the IP address of that other system. So, when my computer wants to connect to the router, it sends out an ARP request stating, "Hey, who has 192.168.1.1? Tell 192.168.1.100." This message is broadcast to every system on my network. My router, recognizing its own IP address (192.168.1.1) sends a reply back to my computer (192.168.1.100) stating, "I have 192.168.1.1 and its MAC address is 00:01:45:a0:d2:30".
Still with me? Okay, here's where I get to the purpose of this post. Ethernet requires a minimum of 64 bytes (512 bits) be put "on the wire". I won't go into the reasons here, but this 64 bytes includes a 4-byte CRC. The CRC is typically not included, so that the minimum size from most programs that look at frames is 60 bytes. If you happen to be using Wireshark, you can use this program to capture the frames directly off of your network. I use it quite a bit just to better understand networking.
One thing that I noticed, though, was that I would look at ARP requests and notice that they were only listed as having 42 bytes. Actually, that's the actual size for an ARP request. But Ethernet requires a minimum of 60 bytes (again, not including the 4-byte CRC). In order to make the minimum, the computer will add 18 bytes of padding (simply a bunch of 0s) to puff up the frame to make it the 60 byte minimum. But Wireshark was not showing those padding bytes. Big deal! you might say. The problem is that there are known attacks using padding bytes to pass malicious data. So, why is Wireshark not showing those padding bytes?
The short answer is because Wireshark doesn't see those bytes. The 42 bytes shown occurs when Wireshark is run to capture frames from the same NIC card as which the frames originate. In other words, if I'm running Wireshark on my desktop and capturing packets from this same desktop, when the ARP request goes out, Wireshark will only show it as being 42 bytes long. The ARP replies, however, since they originate from a different computer, show the proper length of 60 bytes. However, I've looked at ARP requests from my desktop using Wireshark running on a different computer. All of the ARP requests, both requests and replies, showed as being 60 bytes, the Ethernet minimum. In short, this means that the NIC is adding the padding at some point that Wireshark cannot see it.
That's the answer why Wireshark shows some frames as being less than the required Ethernet minimum. It only happens when capturing frames originating from the same system Wireshark is running on and its because there are parts of the NIC that Wireshark does not have access to.