Decrypting 802.11 // File provided / Dumpcap

Question

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.

Accepted Answer

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

Be careful with all of the non-alphabet characters in your password as Wireshark may not handle them.
I used the Wireshark.org PSK calculator (https://www.wireshark.org/tools/wpa-psk.html) to determine the PSK and used that in Wireshark instead of messing with your password. The PSK - you should get the same thing: 328473e458e3dde91d3ad7e665502838c687b04fd249a4bb415ffa7d3a39e088
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 (https://www.amazon.com/TP-Link-Ethernet-Sheilded-Replacement-TL-SG105E/dp/B00N0OHEMA/ref=sr_1_5?ie=UTF8&qid=1508106778&sr=8-5&keywords=managed+switch) 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.