A city employee SSID capture shows EAP Request Identity looping and the TLS tunnel never establishing. What is the best protocol-analysis conclusion?
Select an answer to reveal the explanation.
Short Explanation
If the door keep asking 'who’s there?' and never hears an answer, you don’t resurvey the parking lot—you fix the name tag and the guard desk. An EAP Identity loop is that stuck greeting before the TLS tunnel even starts.
Full Explanation
A city employee SSID capture showing EAP Request Identity looping with the TLS tunnel never establishing indicates the 802.1X/EAP exchange is stalling at identity or TLS setup. Investigate client identity response, EAP method negotiation, or RADIUS path rather than blaming RF coverage alone when associations reach 802.1X but never finish. Expert protocol analysis separates RF association success from AAA completion.
Claiming identity loops always mean the AP channel width is 160 MHz and must be forced to 20 MHz invents an RF width cause for an AAA stall. Saying EAP Request Identity frames are multicast Beacons and that looping them is normal on every secure SSID misclassifies unicast EAP as beacons. Asserting TLS never runs over EAP so the capture must be filtered incorrectly for DHCP only denies EAP-TLS/PEAP tunnel establishment.
Exam caveat: identity loops point to client/IdP/RADIUS issues after 802.11 auth/assoc succeeded. Operational check: confirm Association Response success, then trace EAP identity requests/responses and RADIUS Access-Request timing; fix cert/method/identity issues before surveying RF for “coverage” on a working PHY. Parallel-path a RADIUS connectivity test from the AP/controller while the identity loop runs so RF and AAA owners see split evidence in one window.