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

Wireshark does not decrypt WLAN UDP broadcast packet from AP

0

I am am trying to understand why Wireshark is not decrypting the WLAN UDP broadcast packets from the AP.

In the example below you can see the UDP packet is sent (and decrypted) when sent to the AP in frame 68, however when it is rebroadcast by the AP in frame 70 Wireshark does not decrypt the packet. Can anybody explain why? is there a way to correct this?

alt text

asked 10 May '16, 09:22

mw-ed's gravatar image

mw-ed
6235
accept rate: 100%

edited 10 May '16, 09:25


2 Answers:

1

All data frames to the AP (ToDS) are actually unicast at layer 2, so would be encrypted using the unicast key, key index 0. Frames sent from the AP (FromDS) could be either unicast, again encrypted with key index 0, or multicast/broadcast, which could be using either key index 1 or 2. To see which key is in use, open the CCMP parameters field. So it appears Wireshark is congnizant of the PTK in this case, as it can decrypt the unicast frames. However, it is struggling with the GTK, or group key. They get out of sync, so it is possible Wireshark does not actually have it. It comes across with the four-way EAPOL handshake, assuming you are using WPA or some variant, but can be updated with a group rekey event (two-way handshake).

I have seen this behavior before, but never did a deep dive on it. Some tips:

  1. Make sure the eapol frames are there from a 4-way handshake, so we know you have the PTK.
  2. Save the trace after seeing this issue, and then reload. That can usually help a lot.
  3. Move the saved trace to airdecap-ng, one of the aircrack-ng tools.

Be sure there are no other GTK rekey events - these would be encrypted with the unicast key so should be visible if you see the other unicast traffic.

answered 10 May '16, 10:27

Bob%20Jones's gravatar image

Bob Jones
1.0k2515
accept rate: 21%

@Bob Jones, found this good enough to qualify as an answer.

(10 May '16, 23:35) Jaap ♦

0

WPA decoding in Wireshark was improved with the 2.0 release and the fixes also got backported to Old Stable some releases ago. But Wireshark 1.10.x is still using the old buggy code.

Wireshark 2.0 itself also still has known wpa decoding issues, so please try one of the current versions (2.0.4, 1.12.12 or 2.1.1). They have no known Wpa decoding bugs and support more than one (more or less random) group key. GTA rekeys really should be no longer an issue with any of those versions.

If that's not working I would like to get the capture to find out what's wrong. (Fyi: I have reworked the wpa decoding and know the code. If it's an bug I can fix it.)

answered 17 Jul '16, 03:09

Alexander%20Wetzel's gravatar image

Alexander We...
62
accept rate: 0%