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.

Running Windows under VMWare on Ubuntu

As I've posted previously, I'm trying to figure out how to perform under Ubuntu all of the tasks I used to perform under Windows. Unfortunately, I'm having difficulties. This was expected. And I'm not blaming Ubuntu. If as many people were making software and hardware for Linux as they were for Windows, this wouldn't even be a topic of discussion. As it is, right now, I can't find a working Linux driver for my old Visioneer scanner. That means I still need Windows. I've had my system as a dual-boot. In those cases where I need Windows, I restart the system, bring up Windows, perform the task, then restart back into Ubuntu. It wouldn't be so bad except for the fact that, with a lot of the garbage that Windows requires (here's looking at you, Norton), booting up in Windows takes minutes.
I may have found some better solutions. First, on the scanner. I tried out several of the emulator and virtual machine programs that are freely available. These include Wine (an emulator of Windows that runs on Linux & Unix), Virtualbox (a virtual machine) and VMWare Player (another virtual machine). NOTE: While VMWare Player is free, most or all of the other VMWare programs cost money. Frankly, in my opinion, VMWare Player works best for me. I now have a (n almost) fully functional Windows XP system running on top of my Linux system. If I need to do some scanning, I can bring up the virtual machine (takes about 30 seconds), perform the scans (which are scanned into a shared folder between the Ubuntu host and Windows XP guest system), and close it down. Done. Also, if there is ever a problem with the Windows system, I have a stable copy backed up. That's the wonderful thing about virtual machines. They are simply a collection of files. BIG files (we're talking almost 10 GB for the WinXP stuff), but still just files. If the working copy is corrupted, delete it, and put a fresh version in its place. No muss. No fuss.
Second, on the video-related stuff, I occasionally play around editing video, such as when I made a short video for my father based on some pictures and video clips taken at his 70th birthday party. Nothing fancy. Fortunately, Ubuntu has several video editors available. I've chosen Kino, and so far, its working fine. What this means is that I can now see a not-too-distant point in the future when Windows will not be talking directly with my hardware. It will be safely ensconced in virtual machine where any damage it can do will be minimal at best. It also means its one more step when Windows won't be necessary at all.