Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

802.11 malformed packets in monitor mode #92

Closed
natiya opened this issue Oct 6, 2017 · 14 comments
Closed

802.11 malformed packets in monitor mode #92

natiya opened this issue Oct 6, 2017 · 14 comments
Labels

Comments

@natiya
Copy link

@natiya natiya commented Oct 6, 2017

I'm capturing 802.11 packets in monitor mode and all of them are malformed. I attached an example of one of the capture here. If you filter by eap or eapol, that should be a sucessful handshaking, but I can't see it because it's all malformed.

I tried two WiFi adapters:

  • NetGear AC1200
  • Cisco LINKSYS WUSB100

And I used:

  • tshark command line
  • dumpcap command line
  • Acrylic

I repeated the same process in a Windows Server 2008 with an AirPcap dongle and it works perfectly.

I'm not sure what component is failing:

  • Windows 10
  • my adapters
  • Wireshark/Npcap on Windows 10

I run the capture from 2 different PCs, both using Windows 10, and same issue happens.

My problem also is that AirPcap is not available for Windows 10.

Any solution?

@dmiller-nmap
Copy link
Contributor

@dmiller-nmap dmiller-nmap commented Oct 8, 2017

Probably related: nmap/nmap#1001

@dmiller-nmap
Copy link
Contributor

@dmiller-nmap dmiller-nmap commented Oct 8, 2017

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.

@natiya
Copy link
Author

@natiya natiya commented Oct 9, 2017

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?

@dmiller-nmap
Copy link
Contributor

@dmiller-nmap dmiller-nmap commented Oct 18, 2017

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

@natiya
Copy link
Author

@natiya natiya commented Oct 18, 2017

@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?

dmiller-nmap referenced this issue Oct 23, 2017
Only the BPF header must be contiguous. By treating Radiotap header
specially, we ended up with uninitialized bytes at the beginning of
802.11 frames, and an equivalent amount truncated from the end.

Also, we were not considering the length of the Radiotap header in
checking if there was enough free space in the circular buffer. This
could lead to overlapping/overwriting frames that should be dropped
instead.

Possibly related issues:
* nmap/nmap#1001
* nmap/nmap#1028
* nmap/nmap#1036
@dmiller-nmap
Copy link
Contributor

@dmiller-nmap dmiller-nmap commented Oct 23, 2017

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.

@natiya
Copy link
Author

@natiya natiya commented Oct 24, 2017

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

@dmiller-nmap
Copy link
Contributor

@dmiller-nmap dmiller-nmap commented Nov 1, 2017

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/

@natiya
Copy link
Author

@natiya natiya commented Jan 5, 2018

@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?

@binarymaster
Copy link

@binarymaster binarymaster commented Jul 25, 2018

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.

@gvanem
Copy link

@gvanem gvanem commented Jul 25, 2018

@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
Copy link
Author

@natiya natiya commented Jul 25, 2018

@gvanem
Copy link

@gvanem gvanem commented Jul 25, 2018

@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.

@fyodor fyodor transferred this issue from nmap/nmap May 20, 2020
@fyodor fyodor added the bug label May 20, 2020
@dmiller-nmap
Copy link
Contributor

@dmiller-nmap dmiller-nmap commented Jun 23, 2021

Merging with #76.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

5 participants