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

I'm trying to decrypt some DHCP packets with WPA-2.

Using my key, I was able to see the side sending the DHCP Discover and Request (decryption is working), but I am unable to decrypt the packets sending the DHCP Offer and Ack. I have toggled all of the various settings but these packets just show up as encrypted data.

The difference is, the packets I CAN decrypt have a transmitter address AND a Receiver address (destination is broadcast). So they are clearly part of the session. The packets I CAN'T decrypt have a transmitter address BUT both destination and receiver addresses are broadcast.

Is there some way to force Wireshark to treat these packets as being in the same session that I am decrypting?

I just found this unanswered question is a duplicate. Question still stands.

asked 17 Jul '13, 11:36

mtd19's gravatar image

accept rate: 0%

edited 18 Jul '13, 17:21

I can see your problem inside one very old trace I found and observe the same behaviour. Could it be possible for you the check if you have the same issue using WPA/TKIP security? In my case TKIP decryption perfectly works for all 4 DHCP packets.

If you second this maybe there really is an issue within CCMP decryption there

(17 Jul '13, 13:37) Landi

I can't change the security type, this is a WiFi Direct application that uses WPS, not an AP that I can just configure.

(17 Jul '13, 13:53) mtd19

Are you sure the Offer and ACK are inside the trace? In various traces with your problem description I see encrypted data packets but none match the estimated size and mac addresses they should have.

I too have the non-decryptable packets but the transmitter address matches the station and not the AP / DHCP server, so those can't be Offer and/or ACK or the capture setup broke sth. here

(17 Jul '13, 15:03) Landi

I see something like this: DHCP DISCOVER (from A to broadcast/B is receiver) encrypted data (from B to broadcast/broadcast) DHCP REQUEST (from A to broadcast/B is receiver) encrypted data (from B to broadcast/broadcast)

I have Microsoft NetMon on one machine and I used that to match timestamps of the encrypted data packets. It seems like I do have those packets, but Wireshark does not decrypt them.

(17 Jul '13, 15:45) mtd19

Apparently you can't post links at all? Can you access this URL at 4shared? /file/GmZD7tah/DHCP_packets_issue.html

(18 Jul '13, 14:37) mtd19

That is 4shared dot com and then the URI above (these SPAM filters are really annoying)

(18 Jul '13, 14:38) mtd19

Just downloading - btw: you can easily provide traces at without having to register or do anything else. There they are also visible inside a web based - yet limited - wireshark WebUI

(18 Jul '13, 14:41) Landi

I converted a few things to make it easier to follow up --> see answer section

(18 Jul '13, 14:51) Landi
showing 5 of 8 show 3 more comments

Ok, that is indeed stange - because by pure luck pick I was able to find traces that match exactly your problem definition BUT those broadcast packets (in your terms) were "from A to broadcast/broadcast" which resulted out of a capture issue. That's why I asked you to double-check.

Could you upload the trace file or just the DHCP process related frames along with the 802.11 Layer 2 ACKs? I don't need them to decrypt but maybe there is a way to figure comparing those to my traces here

permanent link

answered 17 Jul '13, 15:58

Landi's gravatar image

accept rate: 28%

Akismet thinks I'm spamming...trying again

(1) is DHCP Discover (3) I THINK is DHCP Offer (won't decrypt) (4,13,29) DHCP Request (15, 31) I THINK DCHP Ack (won't decrypt) (32,34) ARP Packets decrypt just fine

(18 Jul '13, 14:37) mtd19

31 can't be a request since it's coming from the station. 32 isn't a DHCP ACK but purely a wireless layer 2 ACK for 31 --> so the only (also timely possible) valid process I could estimate would be Discover(29), Offer(31), Request(32), DHCP ACK(34).

Which of those do and don't decrpyt?

(18 Jul '13, 14:54) Landi

Poor formatting, retrying

(1) is DHCP Discover

(3) I THINK is DHCP Offer (won't decrypt)

(4,13,29) DHCP Request

(15, 31) I THINK DCHP Ack (won't decrypt)

(32,34) ARP Packets decrypt just fine

(18 Jul '13, 16:20) mtd19

Sorry for misinterpreting your previous message - made sense already but where I'm located it's quite in the middle of the night ;)

I'm honest with I'm not sure about what's happening there - but from what I see I'd sucpect a few things: - WPA does exchange keys for broadcast packets during eapol handshake --> seeing multiple DHCP sessions (by timing) indicated multiple encryption handshakes - maybe (!!) there is an issue due to packet loss during the capture making wireshark unable to decrypt the frames sent by/over the AP due to missing GMT/GTK deriving from handshake

What makes me most sceptical is that given the delta times you seem to have scattered multiple DHCP attempts which bring me to the conclusion that there might be some issue with packet loss while capturing.

(18 Jul '13, 16:37) Landi

I'm actually investigating a DHCP issue where I'm seeing these multiple requests 2 seconds apart. So that is expected. I'm reasonably certain this is not a packet loss issue, but I could be wrong

The DHCP transaction ID's are the same so I don't think that is the issue.

I'm uploading the packets with the M1-4 so you can decrypt them to see this issue better yourself. /file/i40BXOVu/DHCP_packets_issue_with_4-way_.html

The WPA-psk is F77E5D0BEFD85A7B0EBBE278ED81013B054D702D0BF6A4545B176840D9C82A0C

(18 Jul '13, 17:02) mtd19

Thank you for providing the trace file.

  1. Regarding Decryption I totally agree with you that there seems to be an issue when having WPA2/CCMP. I could also confirm using my reference tracefiles from a lab.

  2. To your DHCP issue - although not the main part of your question:

The 2 seconds between requests with the same transaction ID indicate packet loss - let's analyse on base of wireless ACKs (46bytes only one mac in it) and the timings. I set a time reference on frame 16 just to see how long the process takes in regard to the DHCP Discover starting it off:

16: DHCP Discover

17: ACK to 16

18: (suspected) DHCP Offer

19: DHCP Request

20: ACK to 19

and then it gets silent :) what is weird is that I don't see ACKs for many frames from the AP e.g. frame 18 - this pattern is going to repeat

then 2 seconds later:

23: DHCP Re-Request <-- fits to why there was no DHCP ACK before

24: ACK to 23

25: (sucpected) DHCP ACK

and again no wireless ACK but also no wireless retransmission, so there is strange. Wireless ACKs in 26+ are way too late to match

then 2 seconds later:

32: DHCP Re-Request <-- would again support the last one didn't make it

33: ACK to 32

34: (sucpected) DHCP ACK

and this time it worked because we have the ARPs ~ 400ms later but again no (wireless) ACK to the DHCP Application acknowledge.

So I'd guess either they were not captured or the station didn't send any ACK but then there should have been wireless retransmits within few hundred ms at max.

To me it doesn't look like a network issue but maybe some weird problem inside the station where the packet gets lost between wireless NIC and DHCP client but that's a complete guess based on the few facts there are given the trace files.

I hope that helped a little - sorry if there were no news to you

(18 Jul '13, 23:21) Landi
showing 5 of 6 show 1 more comments
Your answer
toggle preview

Follow this question

By Email:

Once you sign in you will be able to subscribe for any updates here



Answers and Comments

Markdown Basics

  • *italic* or _italic_
  • **bold** or __bold__
  • link:[text]( "title")
  • image?![alt text](/path/img.jpg "title")
  • numbered list: 1. Foo 2. Bar
  • to add a line break simply add two spaces to where you would like the new line to be.
  • basic HTML tags are also supported

Question tags:


question asked: 17 Jul '13, 11:36

question was seen: 4,114 times

last updated: 18 Jul '13, 23:22

p​o​w​e​r​e​d by O​S​Q​A