As we know, the minimum payload of an Ethernet II frame is 46 bytes (or 42 bytes if 802.1Q tag is present). If the payload is less, padding bytes are added. When capturing on ethernet interface, Wireshark is usually able to dissect these bytes (filter eth.padding).
My question is about what happens to these padding bytes when this frame is sent as 802.11 frame? For example, a TCP ACK frame sniffed from wireless interface going from STA to DS (To DS: 1 From DS: 0) does not have these padding bytes. Whereas TCP ACK frame going from DS to STA (To DS: 0 From DS: 1) does show 6 bytes of padding. Even though Wireshark was not able to dissect them, I assume these last 6 zero bytes correspond to ethernet padding bytes (or if FCS is visible these 6 bytes come just before it).
I have noticed this behaviour from my own captures and, for example, from Wireshark sample capture Http.cap from https://wiki.wireshark.org/SampleCaptures. References from Http.cap are:
- packet 9 going to DS (no padding bytes)
- packet 13 going to STA (padding bytes visible)
Is this expected behaviour or somehow related to specific wireless NICs? I couldn't find any explanation for this from internet nor the 802.11 standard.
Not sure about the setup in sample capture Http.cap, but I will further clarify my test setup.
PC1 <-> Switch1 <-> AP ... Wireless client <-> Switch2 <-> PC2
When I capture on either Switch from a mirrored (SPAN) port, all the TCP ACK frames going to either direction have ethernet padding. Then when I capture on wireless interface with an external capture adapter, only packets going to wireless client do have these padding bytes intact. So it seems that the wireless client is able to strip these padding bytes when the Ethernet frame is translated to 802.11 frame. AP and Wireless client are both identical devices, only their operating modes differ.
