Hello everyone, This post was very helpful in learning about the status of the problem with Meraki MR antennas. In other forums and blogs/posts on the internet, the problem remains the same and there is no concrete solution from Cisco Meraki. The antennas work this way to avoid HSTS and certificate issues, according to the Meraki specialist and the support they have provided me. That's just how MR works. An alternative that also has its complications and that I am still in the process of evaluating and testing is to use DHCP option 114. Knowing how it works in general, it seems like it will work, but upon thoroughly validating the information, complications have already arisen. DHCP option 114 is known as Captive Portal URL. This option allows the DHCP server to provide clients with a specific URL that typically points to a captive portal (for example, on public or corporate Wi-Fi networks with web authentication). How does it work? When a client obtains its IP configuration via DHCP, in addition to the IP, mask, gateway, and DNS, it may receive this option 114. The value of the option is a text string (URL) that tells the client where to redirect the user to authenticate or accept terms. It is common in environments where authentication is required prior to full Internet access, such as hotels, airports, and offices with guest Wi-Fi. What is it for? It automates the delivery of the captive portal URL, avoiding manual configurations. It improves the user experience, as the operating system or browser can detect this option and automatically open the login page. It is used in BYOD solutions, guest Wi-Fi, and networks with controlled access policies. This option is defined in RFC 8910 (Captive-Portal Identification in DHCP and Router Advertisements). Option 114 (DHCPv4) = Captive-Portal Identification. Used to announce to clients that the network has a captive portal and to provide a URI where the client can check its “captivity” status (CAPPORT API, RFC 8908) and obtain the URL of the authentication portal. It replaces the old code 160 (RFC 7710), which is now obsolete. Note: The value of option 114 must be a CAPPORT API URI (not necessarily the login page). The API returns JSON with fields such as captive and user-portal-url. What problems does it solve compared to “classic” portals? It avoids intercepted HTTPS redirects (which trigger alerts/errors due to HSTS and certificates). Ideally, only HTTP should be redirected; option 114 also allows the OS to open the portal directly without relying on interception tricks. Better UX and faster discovery: the customer knows immediately that there is a portal and which URL to go to. Even so, client support varies: • iOS/macOS (14/Big Sur onwards) implement CAPPORT, but there are peculiarities (sometimes the first connection uses the old method and the second uses 114). • Android 11+ incorporates CAPPORT (documented by Google), but adoption may vary by manufacturer. • Linux: systemd-networkd still had support for 114 open; it depends on the distro and version. In my case, I have an integration with Cisco ISE where the solution is even more complicated, so I am still reviewing it.
... View more
