Before association on a Passpoint-enabled civic guest service, the capture shows GAS exchanges querying network selection data. What is occurring?
Select an answer to reveal the explanation.
Short Explanation
Passpoint is like reading the museum brochure through the glass before you buy a ticket—ANQP over GAS hands the client roaming and realm info before association. Seeing those GAS frames means Hotspot 2.0 pre-association discovery is working.
Full Explanation
Before association on a Passpoint-enabled civic guest service, GAS exchanges querying network selection data indicate ANQP over GAS providing Hotspot 2.0/Passpoint pre-association information to the client. Clients learn realms, roaming consortium data, and related selection info before associating. Expert analysis recognizes GAS/ANQP as Passpoint discovery, not as SAE or Block Ack setup.
Claiming the client is completing SAE confirm before any Probe Request is allowed misorders authentication ahead of Passpoint discovery. Saying Block Ack setup is mandatory before Beacons may be decoded on Passpoint SSIDs invents a dependency that does not exist. Asserting the AP forces captive-portal HTTP only inside Probe Responses confuses Layer-7 portals with ANQP information frames.
Exam caveat: GAS/ANQP is the Passpoint pre-association control plane for municipal guest roaming services. Operational check: capture pre-association on the civic Passpoint SSID, filter GAS initial requests/responses, confirm ANQP payloads for realm/roaming data, then proceed to association acceptance testing. Include ANQP realm values in the Passpoint acceptance checklist so GAS success is verified for content, not only for frame presence.