You are using Wireshark to view packets captured from HPE Aruba Networking infrastructure, but you're not sure that the packets are displaying correctly. In which circumstance does it make sense to…

Question

Options

• AWhen the traffic was captured on the data plane of an HPE Aruba Networking gateway and sent to
• BWhen the traffic was mirrored from an AOS-CX switch port connected to an AP.
• CWhen the traffic was captured from an AP with HPE Aruba Networking Central.
• DWhen the traffic was captured on the control plane of an HPE Aruba Networking MC and sent to a

• A
  8% (2)
• B
  4% (1)
• C
  79% (19)
• D
  8% (2)

Explanation

When HPE Aruba Central captures traffic from an AP, the AP decrypts the 802.11 frames internally but forwards them with the Protected Frame bit still set in the MAC header - Wireshark then incorrectly treats the payload as still-encrypted gibberish. Telling Wireshark to ignore the protection bit (and IV) lets it properly decode the already-decrypted payload, making the capture readable.

Why the distractors are wrong:

• A & D describe captures taken at the gateway data plane or MC control plane - traffic at those points has already been converted to Ethernet/IP frames, so there are no 802.11 protection bits involved at all.
• B (AOS-CX switch port mirroring) captures the wired Ethernet side between the switch and AP - again, raw 802.11 frames are not present, so the protection bit issue never arises.

Memory tip: Associate "AP capture via Central = decrypted body, protected header mismatch." The AP does the heavy lifting (decryption) before handing off the frame, but it can't strip the MAC-layer flag that Wireshark relies on - so you must tell Wireshark to look past it.

No community discussion yet for this question.