Wireshark captures

Hi community experts,

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.

Hello Simon,

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.

Let me know if this helps answer your question!

Hi Casey

Thanks for the reply. So it does not matter whether i enable or disable the ‘trim data payload’ option before starting the capture?

What about the tp-link archer t9-uh v2 adapter?

Thanks for your help. Appreciate it.



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

Hi Simon,

I’ve the same problem of you with 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 hope the developer could fix that.


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.

Done! I’ve created a ticket to capture this issue.

Hello Casey and Brian,

thanks for having taking in account this issue.


1 Like

Hello Casey,

With the new release the issue is still present, maybe in an another version.


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?

Hi Gecko,

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, which does NOT trim data if the option is not checked.


Hello Ryan,

Great news, the “not Trim option” work right now with the version and now we could decrypt traffic.

Thanks to the developer to have correct this important function.


Hi Ryan

I’m all good. No worries.

Appreciate your efforts and getting back to me.