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 #1028

Open
natiya opened this Issue Oct 6, 2017 · 13 comments

Comments

Projects
None yet
4 participants
@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

This comment has been minimized.

Show comment
Hide comment
@dmiller-nmap

dmiller-nmap Oct 8, 2017

Probably related: #1001

dmiller-nmap commented Oct 8, 2017

Probably related: #1001

@dmiller-nmap

This comment has been minimized.

Show comment
Hide comment
@dmiller-nmap

dmiller-nmap 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 #1001. That had a malformed radiotap header, and the headers seem to be formed correctly in your example dump.

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 #1001. That had a malformed radiotap header, and the headers seem to be formed correctly in your example dump.

@natiya

This comment has been minimized.

Show comment
Hide comment
@natiya

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

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

This comment has been minimized.

Show comment
Hide comment
@dmiller-nmap

dmiller-nmap Oct 18, 2017

I have left detailed instructions on #1036 for running Windows Driver Verifier, which may give us a crash dump that I can debug. Please follow these instructions: #1036 (comment)

dmiller-nmap commented Oct 18, 2017

I have left detailed instructions on #1036 for running Windows Driver Verifier, which may give us a crash dump that I can debug. Please follow these instructions: #1036 (comment)

@natiya

This comment has been minimized.

Show comment
Hide comment
@natiya

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

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 pushed a commit to nmap/npcap that referenced this issue Oct 23, 2017

Fix some issues with Radiotap headers.
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

This comment has been minimized.

Show comment
Hide comment
@dmiller-nmap

dmiller-nmap 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.

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

This comment has been minimized.

Show comment
Hide comment
@natiya

natiya 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!

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

This comment has been minimized.

Show comment
Hide comment
@dmiller-nmap

dmiller-nmap 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/

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

This comment has been minimized.

Show comment
Hide comment
@natiya

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

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

This comment has been minimized.

Show comment
Hide comment
@binarymaster

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

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

This comment has been minimized.

Show comment
Hide comment
@gvanem

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

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

This comment has been minimized.

Show comment
Hide comment
@natiya

natiya Jul 25, 2018

natiya commented Jul 25, 2018

@gvanem

This comment has been minimized.

Show comment
Hide comment
@gvanem

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

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment