Probably related: nmap/nmap#1001

It looks like the "IEEE QoS Data" layer expects the last 4 bytes to be some a Frame Check Sequence, but as you can see in packet 1408, that is actually a continuation of the EAP data (e.g. the -0\0\0 is the end of the "WFA-SimpleConfig-Enrollee-1-0" string). So something ought to be adding the frame check sequence and it is not doing so. I'll check to see if this is something Npcap is supposed to do or not.

I am now doubting that this is related to nmap/nmap#1001. That had a malformed radiotap header, and the headers seem to be formed correctly in your example dump.

Is it a sync issue? Maybe the adapters aren't able to capture packets at the speed they are transmitted...but it's weird both of them failed, isn'it?

I have left detailed instructions on #90 for running Windows Driver Verifier, which may give us a crash dump that I can debug. Please follow these instructions: https://github.com/nmap/nmap/issues/1036#issuecomment-337450644

@dmiller-nmap thanks for your instructions. I followed them, but I have the same issue (malformed 802.11 packets). I think I would need the a driver-debug version. I didn't get a blue creen on Windows and the dmp files in my MiniDump folder were modified on 28th September for the last time.

Any other suggestions, please?

Unfortunately, I didn't find the (possible/untested) fix for this until after Npcap 0.95 was released, so you'll have to wait a bit until I can get it tested and packaged. Npcap 0.95 still has this bug.

@dmiller-nmap do we need to wait to the new version, Npcap 0.96? Do you know when will it be realeased? Thank you!

Npcap 0.96 has been released, which ought to solve this issue. Please let us know so we can close this issue. https://nmap.org/npcap/

@dmiller-nmap I also installed the latest version of Npcap, 0.97, and this problem is still there. All the packets captured are malformed. Is there anything else I can try or any information I can provide so you can have a look at it?

This issue is still actual, I've just tested in my environment:

• Npcap 0.99-r7 (latest release)
• Wireshark 2.6.1
• Broadcom 802.11n (built-in wireless, PCI\VEN_14E4&DEV_4727)

There are always 4 excess bytes appended to the 802.11 packet data. If you remove these 4 bytes from the packet end, it would not be marked as "malformed" anymore.

Attached capture sample: broadcom.cap

I've also tested with RTL8187L-based USB Wi-Fi adapter, and it have the same issue while capturing 802.11 packets.

@natiya You wrote My problem also is that AirPcap is not available for Windows 10.

What do you mean? I use Win-10 (x64, Intel I7 CPU) and AirPcap. Works just fine.

@natiya
Make sure airpcap.dll is on your PATH. Test using CaceTech's / RiverBed's tools.
E.g. (in my case) C:\Program Files (x86)\Riverbed\AirPcap\AirPcapReplay.exe. This uses airpcap.dll.

But since my AirPcap adapter cannot transmit (and supports 2 GHz only), I'm not sure a "WiFi Replay Attack" could work.

Merging with #76.