Hi everyone, Wireshark cannot capture EAPOL packets in monitor mode. I am working on Kali Linux 2016.2 64 bit OS. I have exactly the same problem and have same network adapter which is mentioned in the following link: I've typed these commands to get in monitor mode: I've added decryption key [Passphrase:SSID] in 802.11 protocol. Could anyone help me? asked 13 Jan '17, 14:03  instantcrush edited 13 Jan '17, 14:03 |
One Answer:
We can probably help you, but not with the limited information you provide. The reference question had a number of comments and a technique to start but you did not provide a trace nor do you say if you followed the procedure described. There are MANY reasons why one can't get this to work. Are you on the right frequency band? Are you on the right channel? Do you know how to identify the device under review? Having the key entered will not help the capture - it will decrypt if you get the 4-way eapol frames, but has no impact on capture. Make sure you shutdown the network manager as well - one of those commands above may do it (I don't use the aircrack-ng scripts so don't know exactly what they do) so suggest to shutdown the network manager and make sure the proper channel is set, and follow the procedure described in the other question. If you don't have any luck, post a trace and we can figure out why it doesn't work. answered 13 Jan '17, 14:25  Bob Jones showing 5 of 15 show 10 more comments |
Thanks for reply, I've followed provided steps in the link and then got a cloudshark account but they suggested this forum. As you mentioned: There are MANY reasons why one can't get this to work. Are you on the right frequency band? Are you on the right channel? Do you know how to identify the device under review?
I don't know how to configure these, I looked up wiki but didn't encounter with those. Can you suggest me a proper source?
Try
https://wireless.wiki.kernel.org/en/users/documentation/iw
This will set channel and other settings. Check your status with:
[email protected]$ iw dev
Then you can use ifconfig to bring interface up and down, and set the channel with iw. Set to same channel the ap is on.
I've configured moni0 interface with below command:
iw phy phy0 interface add moni0 type monitorthen
ifconfig moni0 upand
ifconfig wlan0 downMy AP channel is 11 so I typed:
iw moni0 set channel 11iw dev command output without addr is:
phy#0 Interface moni0 ifindex 4 wdev 0x2 type monitor channel 11 (2462 MHz), width: 20 MHz (no HT), center1: 2462 MHz txpower 20.00 dBm Interface wlan0 ifindex 3 wdev 0x1 type managed txpower 20.00 dBmEven if I did those, when I capture packets with moni0 on Wireshark. I cannot see EAPOL packets and even my AP's SSID. There are just 802.11 protocols with encrypted data.
Your commands for prepping the interface look OK, but you should see beacons from your AP. These are sent at relatively low rates so are generally easily picked up. Where are you looking for your AP's SSID? It should be present in probe responses, and is likely in a beacon, but it is possible to mask by configuration in the beacons.
If you are seeing 802.11 frames in Wireshark, but not yours, I can only imagine the AP is really off, or you are on the wrong channel. Even with all the capability stuff we have to deal with now, your should see SOME traffic - beacons, ACKs, etc (i.e. mgmt and control frames) are generally sent at low rates so are easy to pickup. The hard part is the unicast data frames.
Other wifi chipsets have issues picking up unicast frames and perhaps the behavior you are seeing is consistent with that type of issue; a trace would confirm that you get nothing but broadcast and multicast frames. However, I discount this because I have never seen that adapter referenced have this problem. TP-Link TL-WN722N has an Atheros chipset which works well for many. If you put a short trace in cloudshark we may be able to identify what the issue is faster.
First I could not see my AP's becaons, now I can. However, as you mentioned I am only able to see my AP's beacons and probe responses. How can I capture eapol, http, tcp traffic on my AP. Also, I'm very thankful to your quick responses.
https://www.cloudshark.org/captures/3cee3898f881
Here is my capture
I looked at the capture and it looks good. You have all traffic types - multicast/unicast/broadcast, up to MCS7 for 802.11bgn. This is consistent with the TP-Link capture adapter. These are some data frames I pulled out that are encrypted:
I don't know the device you want to decrypt from so could not analyze signal strength. Let's pretend it's healthy, so when running a capture like you have here, did you reboot the device, or otherwise have it connect to this SSID, on this channel? If the device in question is capable of both 2.4 and 5 GHz, it may prefer 5 GHz. Since your capture is only 2.4, you would miss it. You need to force things - set the AP to have the SSID on only 2.4GHz, and then reboot the device or otherwise have it connect. Post that trace if you don't see the eapol frames - also look for the whole sequence of request/response frames:
Probe
Authentication
Association
EAPOL
Do you see any of these? Is the device in question in this trace?
Yes it has connected to my AP's SSID with same channel. My AP has only 2.4 GHz. However the output is same as my previous capture. I'm running on guest OS, is this cause a problem? Is my problem only decryption of frames or a frequency mismatch? I provided psk decryption key and configured frequency channel correctly. Are there any required configuration to get eopal packets?
Whats the mac of the device you want to evaluate? We need to check the capability. Decryption is not an issue until you get the eapol frames. Is the capture system in the vm?
Whats the bssid? If the frames are sent at a rate/capability the capture supports you should get them.
Yes the capture system is in the VM. SSID is Cankistan. For information, I'm not using RADIUS authentication, is that cause a problem?
The trace looks healthy except for what you say is not there...
Enterprise should not matter. That will end in a 4-way handshake. With WPA2-Personal, there is only a 4-way EAPOL handshake after probing/authentication/associating.
I looked through the trace again and there is are a couple of probes from devices not connected to that BSSID, so no auth/assoc/eapol action. Just to be clear: start the capture, then have the device leave that SSID. Then have it come back - you can move to another network, or reboot, or whatever, but it has to leave and then come back. When it (re)associates, it will rekey so will go through the 4-way process again.
The beacon says four devices are on that SSID, but Wireshark really only shows two:
Omnipeek shows three:
I can't explain the discrepancy, nor find that fourth device.
I rebooted my AP during capture, It works! I have 4 EAPOL packets now.
I'm very thankful to you. I'm now able to capture some packets but not all of them. I tried to connect an HTTP server on mobile but those packets weren't captured. What is the cause of this? I can see port 443 data but cannot see port 80's data.
If you found the answer useful to the the question, please accept the answer for others.
Functionally, there is no difference. Maybe you are only using https and not http? Also the eapol frames are generally easy to get - but I expect you may have some problems capturing actual data. Your capture device is a single stream while the AP supports two spatial streams. If a client connects that supports two spatial streams, and has a healthy RSSI, it will usually use a higher MCS index than your capture device will support so you will miss those frames. You will, however, still pickup control frames as these are usually sent at low data rates.
The HT IE in the beacon tells us what the AP supports, and the probe requests and association requests from the client will tell you what the client supports. I haven't seen those for the device so I can't comment. Something to watch out for.
Thanks for all your kind efforts. I try to capture all udps by using all connected devices.