RFC8910 Captive Portal

Я знаю, что это уже обсуждалось, но у кого-то получалось? Вот что я сделал на данный момент. У нас установлен действующий сертификат, и включена опция DHCP 114. В Wireshark я вижу запросы опции 114 от клиентов:

Option: (55) Parameter Request List  
Length: 9  
Parameter Request List Item: (1) Subnet Mask  
Parameter Request List Item: (121) Classless Static Route  
Parameter Request List Item: (3) Router  
Parameter Request List Item: (6) Domain Name Server  
Parameter Request List Item: (15) Domain Name  
Parameter Request List Item: (108) Removed/Unassigned  
Parameter Request List Item: (114) DHCP Captive-Portal  
Parameter Request List Item: (119) Domain Search  
Parameter Request List Item: (252) Private/Proxy autodiscovery  

А вот как выглядит ACK:

Option: (114) DHCP Captive-Portal  
Length: 38  
Captive Portal: https://hotspot.xxxxxx.com/api  

Вот что я получаю, когда заходу на эту страницу через HTTPS:  
{  
“captive”: true,  
“user-portal-url”: “ https://hotspot.xxxxx.com/login ”,  
“can-extend-session”: true,  
“info-venue-url”: “ https://hotspot.xxxxxx.com ”  
}  

api.json хранится в папке hotspot. Но я не вижу никаких запросов к API captive portal, вместо этого вижу старый метод (captive.apple.com — get-hotspot / Generate 204 + 302 редиректы). Тестировал на Android 11, iOS 15 и Big Sur. Есть идеи, как двигаться дальше? Что ещё можно проверить? Что ещё нужно сделать, чтобы это заработало? Читал, что клиент должен иметь возможность обращаться к oscp или ntp-серверам для проверки сертификата, но как понять, происходит ли это тут? Mikrotik говорит:  
«Это поле опции DHCP включается автоматически, но только если на роутере настроено DNS-имя и установлен действующий SSL-сертификат (чтобы страницу логина можно было открыть по HTTPS). Когда эти условия выполняются, отправляется специальная опция DHCP с ссылкой на https:///api. Эта ссылка содержит информацию в формате JSON, которая сообщает клиенту статус captive portal и местоположение страницы входа.»