Like to ask about Eye P.A with wireshark captures. I have the recommended Edimax wireless adapter and have sent captures to wireshark. No issues. The question I like to ask is that the protocol I see are all 802.11 instead of the actual protocol used, e.g.HTTP or HTTPS or RADIUS or EAPoL, etc.
I see related YouTube videos and saw in the background in the wireshark captures in the video shows the actual traffic protocol. thanks.
After conferring with an engineer, it appears that when the Edimax adapter is used as a source, we trim data packets and do NOT save all of the data inside the 802.11 frame. We do this because the data is usually encrypted and can only be decrypted with the WPA2 password and capture of the 4-way handshake.
The YouTube video was most likely showing a .pcap taken from an entirely different hardware source and therefore without the above trimming methods.
Hi Simon! If you want to decrypt the upper protocol layers either adapter is fine. You will need to disable âtrim data payloadâ and capture the client associating to the network in order to capture the 4-way handshake, which establishes the encryption keys.
Hi Ryan,
Thanks for the quick response. I will have to start the capture first and then associate the client device to the AP in order to decrypt the upper protocol layer.
Hi Ryan, sorry to be a pain. I tried again. I associate the Edimax adapter to my wireless first before starting capture (without trimming data payload). I then associate target device to the wireless. I could see the 4 Eapol packets from the target device but it was all 802.11 protocol for the data frames.
Do I need to decode anything on wireshark or is my capture procedure wrong? Appreciate your advice. Thanks
Iâve the same problem of you with 2.3.0.22 or older version and the recommanded device Edimax or Alfa AWUS1900.
Whatever you disable or not âtrim data payloadâ, EyePA always remove the payload.
If we look at the frame info in wireshark, we can see the âbytes capturedâ value is lower
I understand the logic of this⌠but it should be something that can be toggled. There is a checkbox to trim payload⌠if I leave it unchecked I should be able to capture the full payload regardless of whether the payload will be encrypted or not. A bit frustrating.
I agree @ngjones, if the trim payload setting isnât working, thatâs a bug. @casey, can you please make sure there is a ticket for this in the bug tracker? Thanks for reporting this @simon.limkm and @digtheweb.
I am quite disappointed in Metageek. This is a problem that causes a failure of one of the essential functions of the Eye P.A. software. It was detected as a bug and a ticket was created 5 months(!) after the bug was reported. After opening this thread, two software updates were released that did not fix the bug.
When can your customers expect to get an update to use the features they paid for?
Please keep in mind that Eye P.A. version 2.2.4 here does not have the Trim Data Payload bug. For a quick fix, you can always install that slightly older version which performs as expected.
Feel free to reference the release notes here to see whatâs changed since 2.2.4.
We appreciate your patience while our team works on a more permanent fix.
I apologize for our slow response to this issue. It is essential for Eye P.A. to be able to do a full packet capture and not trim all data. We, MetaGeek took too long to resolve this issue, and I am sorry for that.
We had fixed the trim data issue last week, and were prepping a larger release for next week⌠and decided to do a quick build to release the trim data fix immediately. Here is a link to version 2.3.1.11, which does NOT trim data if the option is not checked.