Hotel guests never see the portal. The pre-authentication filter allows the portal and blocks DHCP. A guest that is given a static address can open the portal. What is the filter blocking that the guests need first?
Select an answer to reveal the explanation.
Short Explanation
You’ve already shown that the portal itself is reachable with a static address. The filter is blocking DHCP, which guests need to get an address before they can load the portal. The SSID name and RF tag are not what prevents them from getting an address.
Full Explanation
A guest needs an IP address before a browser can load the portal. The pre-authentication filter allows the portal but blocks DHCP, so guests cannot get an address and never reach the page. A guest with a static address can open the portal, confirming that the portal is permitted and that getting an address is the step blocked first. The portal is not the blocked requirement: allowing it is consistent with the static-address test. The SSID name is not something the filter must permit before a guest can request an address. The RF tag is not what the filter consults in order to offer DHCP. The exam caveat is that a static-address test shows the portal is reachable in that test; it does not mean guests using DHCP can reach it while DHCP remains blocked. As a practical check, permit DHCP in the pre-authentication filter, remove the guest’s static address, and confirm that the guest receives an address and then sees the portal. Retest one live client and check the live counters against the expected result before changing the rest of the floor.