Huge thanks to our Platinum Members Endace and LiveAction,
and our Silver Member Veeam, for supporting the Wireshark Foundation and project.

Wireshark-dev: [Wireshark-dev] wireshark seems to not correctly follow WPA2 rekeying

From: Avery Pennarun <apenwarr@xxxxxxxxx>
Date: Sat, 11 Oct 2014 07:01:30 -0400
Tested with wireshark 1.10.6 and 1.12.1.

See attached pcap, which I've trimmed down to a minimally reproducible
test case.  I created this by setting up hostapd to rekey very
frequently:

wep_rekey_period=10
wpa_group_rekey=10
wpa_strict_rekey=1
wpa_gmk_rekey=9
wpa_ptk_rekey=10

And then attached a station to it, generating some traffic.

For this test data, the SSID:password is TestSSID and 01234567.

Here's what we see:
- Packet #10-28: initial EAPOL exchange
- Packet #29-164: some successfully decoded traffic
- Packet #165-1308: group key rotation (probably not relevant, but
just in case...)
- Packet #1308-1430: more successfully decoded traffic
- Packet #1431-1439: session key rotation
- Packet #1442-end: traffic does *not* decode successfully.

I would have expected that since the rekeying was captured correctly,
wireshark would be able to continue decoding after the rekeying is
completed.

I captured this traffic on a Macbook Air (not participating in this
interaction) with 'tcpdump -I".  For wireshark to decode the first
part, I had to set "Ignore the protection bit" to "Yes - with IV" in
Edit | Preferences | Protocols | IEEE 802.11.

Note: I've confirmed that the station and AP were able to communicate
during the entire session.  In case it matters, the client is a Linux
box with ath9k and wpa_supplicant and the AP is a Linux box with
ath10k and hostapd.

Does anyone have any suggestions for what I might be doing wrong, or
if there is a bug in wireshark?  I'd be surprised if it simply can't
handle rekeying and nobody has noticed.

Thanks!

Avery

Attachment: rekey-bug-cleaned5.pcap.gz
Description: GNU Zip compressed data