Some 802.11 drivers pad between 802.11 header and payload, but Npcap doesn't set the IEEE80211_RADIOTAP_F_DATAPAD flag

See Wireshark bug 15010 for details. It appears that a Netgear A6210 adapter, with Netgear driver v1.0.0.39, adds two padding bytes between the end of the 802.11 header and the beginning of the 802.11 payload to "helpfully" put the 802.11 payload on a 4-byte boundary. (4-byte boundary in what the adapter puts in memory, not 4-byte boundary in the packet data including the Radiotap header.)

Some Atheros chips did this, which is why Radiotap's Flags field has a "frame has padding between 802.11 header and payload (to 32-bit boundary)" bit. Both tcpdump and Wireshark test this bit and skip over the padding as necessary.

In UN*X, drivers generally supply the radiotap header themselves, so the driver can set that flag if necessary.

Unfortunately, the Windows interface for 802.11 adapters may not allow Npcap to determine this, so this might require a quirks list in Npcap.

Start by reviewing Npcap's handling of radiotap headers and the Windows 802.11 adapter metadata path. Determine whether IEEE80211_RADIOTAP_F_DATAPAD can be detected or requires an adapter quirks list. Done means padded 802.11 frames are identified correctly and the flag is handled compatibly with tcpdump and Wireshark.