This is a static archive of our old Q&A Site. Please post any new questions and answers at

Decrypting 802.11 // File provided / Dumpcap


Hi forum, I did my best to resolve this issue on my own and have looked at numerous similar issues, but none have helped. I am not an expert and any assistance is appreciated.

I am trying to capture lengthy amounts of traffic with dumpcap to be later inspected for HTTP "Post" but have encountered difficulties in testing. Not only is HTTP traffic not being decrypted, but no packets at all respond to the proper key in wireshark.

Details: Captured by dumpcap on kali linux with command "sudo dumpcap -i 2 filesize:200000 -b files:2500 -B 1024 -w /media/root/CORE/capture/capture.pcapng" It should be noted that -i 2 is wlan0mon on a TP-Link WN722N

The .pcapng was transferred from the capturing device to a laptop running Linux Mint, where the decryption keys were added in the format [password]:[ssid] under wpa-pwd

Password: *removed*
SSID: *removed*

and... nothing? No decryption at all. It should be noted that the network vor is acting as a repeater from SSID: obx and that capturing traffic normally without dumpcap also does not decrypt.

I have tried fiddling with settings here and there without results, in many other threads they recommend an example file to be provided.

link removed following answer

If I have not explained something, or left something assumed that is confusing, please don't hesitate to ask.

asked 15 Oct '17, 14:28

Cevestas's gravatar image

accept rate: 0%

edited 15 Oct '17, 18:24

Verified eapol packets did contain the password I provided with aircrack-ng, after converting .pcapng to .pcap with online converter.

(15 Oct '17, 14:55) Cevestas

One Answer:


The first trace you post decrypts for me with your parameters. A couple of points:

  1. Be careful with all of the non-alphabet characters in your password as Wireshark may not handle them.
  2. I used the PSK calculator ( to determine the PSK and used that in Wireshark instead of messing with your password. The PSK - you should get the same thing: 328473e458e3dde91d3ad7e665502838c687b04fd249a4bb415ffa7d3a39e088
  3. With the PSK, enter into Wireshark as wpa-psk and the trace decrypts.

Filter I used: (wlan.fc.type_subtype == 0x020 or wlan.fc.type_subtype == 0x28) && (wlan.addr == d0:13:fd:3f:a2:28)

You had the 4-way handshake for only this client in the first trace provided. Note that unicast traffic will only be available after the 4-way handshake; prior to this it is likely encrypted with a different private key (or there is no data as the device was not present).

Managing long term captures that are decryptable is problematic and difficult. I would suggest you install a wired captured solution and this would avoid having to decrypt all together. The single biggest issue with wireless networks is packet loss; what are you going to do when your capture system loses any one of those four eapol frames? Then you can't decrypt. It will happen, but I don't know what impact that has on your ultimate goal. Also what happens on channel change? You are sniffing on all possible channels to handle this case (all professional solutions with wireless controllers have the ability to manage the radio environment and adjust channels automagically). Or, you have to remember if the channel changes to change your capture. Then you might be handling a lot of extra traffic that you would not deal with if you only did a wired capture. You can by a small 4-port managed switch from Amazon for like $25 ( that has mirror port functionality. I would spend a lot more than that in wireless capture systems including multiple adapters, solid state drives, plenty of CPU to sort my captures, etc.

answered 15 Oct '17, 15:35

Bob%20Jones's gravatar image

Bob Jones
accept rate: 21%

edited 15 Oct '17, 15:36

Thank you for this answer, I think the reason I did not realize the decryption was infact occurring was the lack of ""color"" When sniffing normally, without monitor mode, I'm used to seeing many more protocols. Even after decryption of the first trace the majority are simply labeled as "802.11"

(15 Oct '17, 15:55) Cevestas

You were right, capturing the needed eapol packets is very uncertain, and excessive and un-wanted traffic is also captured. Could you elaborate on using a wired connection instead? The only spot in the network I can see that would capture all traffic is between the modem and router, but I've read that massive ARP spam from other routers would be captured. Advice?

(17 Oct '17, 09:46) Cevestas

Where you capture depends on the setup. If the router is a home unit with built-in wifi, you are in some trouble. Not sure how to get a wired stream out of the unit to analyze. Some options, though...

  1. Install another AP and sniff between that device and the router (what I would do)
  2. Upgrade the FW on the router, if possible, with something like openwrt and that may allow for mirroring. Other options are DD-WRT and LEDE.

Any of these possible?

I don't know of the ARP traffic you speak of, so can't comment.

(17 Oct '17, 14:55) Bob Jones

I have some experience with openwrt, so ill look into that route. As for arp, the command -f for dumpcap will filter out arp packets.

(17 Oct '17, 16:27) Cevestas