Вход в сеть Wi-Fi никогда не происходит на устройствах Android, но перенаправление работает нормально

У меня настроен Captive Portal с использованием RadiusDesk + FreeRADIUS + CoovaChilli + Nginx.

Перенаправление работает на 100% на любом устройстве (включая Android). Если пользователь еще не аутентифицирован, когда он пытается перейти на любую веб-страницу http://, он, как и ожидалось, перенаправляется на страницу входа в мой авторизованный портал.

Вот где я изо всех сил пытаюсь понять разницу:

  • на устройствах iOS в тот момент, когда вы подключаетесь к этому Wi-Fi, всплывающее окно «Войти» появляется немедленно (как и ожидалось), и оно переходит на мою страницу входа в портал авторизации.
  • на устройствах Android вы можете подключиться к Wi-Fi, но дальше ничего не происходит. Если вы попытаетесь просмотреть, вы будете перенаправлены, но где всплывающее окно «Войти в сеть Wi-Fi»?

Еще более подозрительно то, что у нас в офисе есть Captive Portal (запатентованная система «Cyberoam»), и когда я использую те же устройства Android для подключения к этой сети через Wi-Fi, я немедленно получите всплывающее окно «Войти в сеть Wi-Fi», как и ожидалось. Что случилось с моей установкой?

Вот мои текущие настройки /etc/coova/config:

HS_LANIF=eth2              # Subscriber Interface for client devices
HS_NETWORK=10.1.1.0        # HotSpot Network (must include HS_UAMLISTEN)
HS_NETMASK=255.255.255.0     # HotSpot Network Netmask
HS_UAMLISTEN=10.1.1.1      # HotSpot IP Address (on subscriber network)
HS_UAMPORT=3990            # HotSpot UAM Port (on subscriber network)
HS_UAMUIPORT=4990          # HotSpot UAM "UI" Port (on subscriber network, for embedded portal)
HS_NASID=localhost
HS_RADIUS=localhost
HS_RADIUS2=localhost
HS_RADSECRET=testing123    # Set to be your RADIUS shared secret
HS_UAMSECRET=greatsecret     # Set to be your UAM secret
HS_UAMALIASNAME=chilli
HS_SSID="Struisbaai"
HS_NASIP=127.0.0.1    # To explicitly set NAS-IP-Address
HS_UAMSERVER=$HS_UAMLISTEN
HS_UAMFORMAT=http://\$HS_UAMLISTEN/cake2/rd_cake/dynamic_details/chilli_browser_detect/
HS_MACAUTH=on              # To turn on MAC Authentication
HS_TCP_PORTS="80 23 8000"
HS_MODE=hotspot
HS_TYPE=chillispot
HS_WWWDIR=/etc/chilli/www
HS_WWWBIN=/etc/chilli/wwwsh
HS_PROVIDER=Coova
HS_PROVIDER_LINK=http://www.coova.org/
HS_LOC_NAME="My HotSpot"           # WISPr Location Name and used in portal
HS_COAPORT=3799

Я также заметил, что если я подключаюсь с ПК к своей сети hostpot, я могу ping clients3.google.com получить ответ (до аутентификации!), что не должно быть возможно. Все остальные домены не получают ответа (как и ожидалось). Это объясняет, почему устройства Android думают, что у них «есть подключение к Интернету», но, насколько я могу судить, я нигде не внес этот домен в белый список в своей конфигурации CoovaChilli...


android coovachilli
person Anselan    schedule 19.02.2016    source источник

Ответы (2)


arrow_upward
1
arrow_downward

А, сам разобрался.

Если DNS-серверы явно не настроены, то по какой-то причине (что-то связанное с настройкой моей сети??) client.google.com разрешен.

Поэтому я просто добавил следующее в свой файл конфигурации:

HS_DNS1=208.67.222.123
HS_DNS2=208.67.220.123

И теперь curl -i client3.google.com/generate_204 возвращает ответ 302, как и ожидалось.

Хотя это довольно странно?

person Anselan    schedule 02.03.2016

arrow_upward
1
arrow_downward

У меня была такая же проблема. Я обнаружил, что домен coova.org получает тот же IP-адрес, что и google.com, во время перевода coovachilli start walledgarden (домены в IP-адреса). Я пропинговал coova.org и google.com и получил один и тот же IP-адрес:

HS_DNS1=208.67.222.222
HS_DNS2=208.67.220.220

Поскольку www.coova.org установлен как разрешенный в файле /chilli/functions, независимо от того, что находится в других ваших конфигурационных файлах, я изменил содержимое файла функций и удалил www.coova.org из «uamallowed», и проблема исчезла - android теперь работает обнаружение портала.

Я действительно не понимаю такого поведения - может быть, какие-то coova/opendns/systemcache, неправильные dnsrecords или что-то в этом роде...

person xklid101    schedule 10.03.2016