Wireshark does not decrypt WLAN UDP broadcast packet from AP

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.

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