In a municipal captive-portal lab on a rogue AP host, why is an HTTP (web) service typically required?
Select an answer to reveal the explanation.
Short Explanation
Captive portals are basically pushy websites. Without a web service answering on the rogue host, there is no page for the library laptop to see. DHCP gets you an address; HTTP gives you the form.
Full Explanation
In a municipal captive-portal lab hosted on a rogue AP system, an HTTP web service is typically required because the portal experience is delivered as web content: login forms, accept-use pages, and redirect targets that browsers and captive-detection flows expect. Without a listener that can answer those requests, associated clients may obtain addressing yet never see a usable portal page. Web services are not a WPA3-SAE offline cracking mechanism and are not interchangeable with handshake cryptanalysis. Browsers do not refuse to join open SSIDs merely because RADIUS is absent; open association and portal presentation are separate concerns. DHCP alone assigns addresses and related options—it does not render HTML login pages. Exam caveat: portal labs usually combine DHCP, DNS or redirection behavior, and HTTP or HTTPS content; omitting the web tier breaks the UX class under test. Operational check: in the authorized civic lab, confirm the rogue host serves the portal URL, watch captive-detection probes, and verify a test client receives the intended page before measuring credential-harvest or awareness outcomes. For municipal and campus engagements, keep the finding language tied to authorized scope, name the building or SSID class affected, and state the residual risk to residents or staff if the rejected option had been chosen. Re-validate after the next change window that the selected control still matches inventory, monitoring, and RoE abort criteria used by the city wireless program.