Hello, I have a wireless capture and I see that the EAPOL exchange is been captured and I have also provided the SSID and key under the 802.11 preferences. I have captured and successfully decrypted wifi traffic before with the same settings. The only difference this time is thatthe Acesspoint is my samsung cellphone mobile hotspot. I have configured the AP to use a specific channel and I have see the traffic flowing in the Wireshark but still unable to decrypt it despite a sucesfull handshake and access to the SSID and key. i am right now only have one client connected. Any pointers will be really helpful. asked 06 Jun '16, 04:45  airhack |
One Answer:
I revisited the decryption keys under the 802.11 preferences option and found out the the AccessPoint incorrectly spelled out instead of AndroidAP it was AndriodAP (keep searching for the diff):D. Thanks Bob on your quick turnaround on my questions, with the correct decryption keys Wireshark is decrypting the packets properly. A couple of more questions: Is the QoS data frame same as the Data frame, which contains the actual payload ? What is the correct filter to use to only filter the capture to a specific network/SID, should wlan.bssid == "ID" work ? I guess so. Thanks Again!! answered 06 Jun '16, 15:24 airhack 1
Yes, they serve the same purpose. The QoS Data frame has QoS information attached in the header and you are likely to see these with 802.11n or higher rates and/or when using WMM.
This is a display filter and is how I would do it. Some shortcuts I use, so I don't type the whole bssid all the time: wlan.bssid[4:2] == <last two="" octets=""> --> example wlan.bssid[4:2] == 45:67 If you want to run a capture filter, i.e. only capture from your bssid, the syntax is different and you need the tcpdump syntax. However, wireless traces are more difficult - not all frames between a client and an AP have the bssid field, so you have to be creative in your filtering to capture everything. For example, ACKs do not have a bssid field, nor do broadcast probe requests from a client. (07 Jun '16, 03:05) Bob Jones Thanks for the display filter. What could possibly reason where all the 4 EAPOL packets are not captured. I am currently capturing traffic from a device and I constantly see only the (message 1 of 4) and (message 3 of 4) been captured. Message 2 and 4 are not captured. Any thoughts ? (12 Jun '16, 16:22) airhack There are a number of reasons why this could be, and it happens often.
I really can't help deduce what might be your specific issue since no real data is provided. (12 Jun '16, 17:49) Bob Jones Packet loss is what I suspected too, the device I am testing a a client VPN device that can connect via wifi. I guess modulation compatibility would be the most likely reason. Will play with the device and AP settings. Thanks!! (13 Jun '16, 12:07) airhack |
A couple of maybe obvious pointers, but since you don't provide any trace, there is nothing I can really do to test it:
We also don't know what traffic you have to decrypt. It needs to be of type Data or QoS Data. It's common when capturing 802.11n or ac traffic to not get many of the data frames due to difficulties with modulation differences between Tx/Rx and capture device. Since there is no trace to review, I can't check for any of this.
I have uploaded the capture at the below location https://drive.google.com/open?id=0ByOYyC-nQZluWnpsS1hNZkwtNnc
To answer your questions, yes all the 4 EAPOl packets are captured and I have reloaded the trace multiple times. I have initiated some web browsing and other stuffs to generate data so there is surely data flowing through.
To add one more point. I am using the Alpha USB adapter which works on b/g range. I assume that the hotspot works in mixed mode since the alpha card is able to see the traffic just not decrypt it. Any pointers ?
If you use a display filter
wlan.ta == ec:1f:72:9c:d0:bb or wlan.ra == ec:1f:72:9c:d0:bb, you'll see only frames sent by your Samsung device acting as an AP, and frames unicast to it by other devices. And among these, there are just a few Data or QoS Data frames.As you haven't published the passphrase, you'll have to have a look at frames 463, 499, 504, 517 yourself. The first two on the list are broadcast frames from the other Samsung device, so I'd assume them to be ARP request and deciphered as such if you provide the right passphrase to Wireshark.
If you extend the display filter to
(wlan.ta == ec:1f:72:9c:d0:bb or wlan.ra == ec:1f:72:9c:d0:bb) and wlan.fc.type_subtype == 0x0028, you should see only this type of frames, and these should be deciphered.If they are not, please change your passphrase on the AP and the test client to a stupid one you would never think of using normally, so that knowledge of it is useless for anyone, take a new capture including the EAPOL exchange and some web traffic, and then change the passphrase back to the one you use normally. Then publish that new capture together with the temporary passphrase, as it would really indicate something weird about the deciphering.
Did you ever manage to get this solved ? I have the same issue with the Alpha AWUS036NH adapater (802.11-b/g/n). On several AP's the Alpha is able to capture session data (random http/https browsing) between Station and AP after 4 way handshake is captured. On other AP's (Asus RT-AC66u) the 4 way handshake is captured but none of the data packets following the handshake is captured, so can not be decrypted.
@JayJay - Following on from your aircrack-ng forum question:
If you start a new question, we can work through the capability differences between the different products. We will need some sample traces (with some beacons and probes/associations for devices) and some other information related to your hardware. We should be able to determine what settings are preventing the proper capture of various wireless frames with Wireshark.
This is a very common issue.