Missing EAPOL in a Multi-Adapter 5 GHz Capture
On a 5 GHz assessment, the target SSID CORP-IOT is beaconing on channel 100 (5500 MHz). You have two adapters: an Alfa AWUS036ACH (RTL8812AU) and a TP-Link TL-WN722N v1 (AR9271). Kismet is running on the Alfa with channel hopping enabled across 2.4 and 5 GHz; airodump-ng is running on the TP-Link writing to a capture file. After sending a targeted deauth to a connected sensor, you see the sensor reassociate in Kismet, but airodump-ng shows no EAPOL frames and no handshake. The capture file contains beacons and probe responses from CORP-IOT but no data frames for that BSSID. You have 20 minutes before the maintenance window closes. You must determine why the capture failed and produce a valid handshake capture without disrupting other floors.
1. Identify the most likely reason the EAPOL frames are missing, citing the adapter and channel behavior.
Read the worked answer
The TP-Link AR9271 is a 2.4 GHz-only radio. It cannot tune to 5500 MHz/channel 100, so airodump-ng on that adapter is capturing the 2.4 GHz side of a dual-band CORP-IOT deployment or unrelated 2.4 GHz beacons, not the 5 GHz BSSID under test. Kismet on the Alfa saw the reassociation because the Alfa is dual-band and hopping. The EAPOL frames are missing because the capturing radio is on the wrong band, not because the deauth failed. Verify with iw dev wlanX info and by checking the radiotap channel/frequency in the capture. Lock the Alfa to channel 100 and use it for airodump-ng; do not expect the AR9271 to capture 5 GHz.
2. Give the exact sequence to lock the correct adapter and validate that the capture is on the target channel before triggering the client.
Read the worked answer
Stop Kismet or disable hopping so it releases the Alfa. Run airmon-ng check kill, then airmon-ng start wlan0 100 (or create monitor and iw dev wlan0mon set channel 100). Run airodump-ng --band a -c 100 --bssid <5GHz_BSSID> -w corp-iot wlan0mon. Confirm the capture before deauth: tshark -r corp-iot-01.cap -Y 'wlan.fc.type_subtype==8' -T fields -e radiotap.channel.freq should show 5500, and iw dev wlan0mon info should show channel 100. Then send a targeted deauth to the sensor's MAC, not a broadcast, and watch for EAPOL message 1/2. If no handshake appears, capture a PMKID or wait for natural reassociation.
3. What Wireshark display filter isolates the 4-way handshake for this BSSID, and why might a PMKID appear without a full handshake?
Read the worked answer
Filter: wlan.bssid == <BSSID> && eapol (or eapol && wlan.addr == <client>). The 4-way handshake is four EAPOL-Key frames; message 1 may already contain a PMKID in the key data if the AP supports it. A PMKID can appear without a full handshake because it is carried in EAPOL message 1 or in the RSN IE, and it can be captured from a single association attempt; it is crackable offline the same way as a handshake. That makes PMKID useful when deauth is unreliable, but it still requires the right BSSID/channel and a client or association trigger.