У меня та же проблема с последним прошивка контроллера (3.8.15). Вы уже нашли какое-нибудь решение? Порт 3478 открыт, и удалённый веб-сервер видит его как "STUN". Так что проблем с этим нет… У меня стандартная установка Apache2, ничего необычного.

Я изначально пытался, но это не решило проблему с авторизацией скорости. Всё равно оставалось случайным, сколько времени уходит, чтобы достичь устройства.

Ну что, после долгих дней головной боли, пытался починить этот медленный процесс авторизации на гостевом портале. Сейчас у меня авторизация отключена (настроено перенаправление на оригинальный URL - ниже это настроено), и авторизация происходит через веб-сервер на PHP на /guest/s/sitename/login, отправляя POST-переменную accept-tou=yes. И нужно настроить Referer, чтобы в нем было id=usermacaddress&ap=apmac&url=urlwhereyouwanttosenduser.
$unifiServer = 'https://controller:9843/guest/s/' .$siteid. '/login';
$refer = 'https://doesntreallymatter/guest/s/' .$siteid. '?id=' .$usermac. '&ap=' .$apmac. '&url=' .$url;
$ch = curl_init();
curl_setopt($ch, CURLOPT_POST, TRUE);
curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, FALSE);
curl_setopt($ch, CURLOPT_SSL_VERIFYHOST, FALSE);
curl_setopt($ch, CURLOPT_RETURNTRANSFER, TRUE);
curl_setopt($ch, CURLOPT_REFERER, $refer);
curl_setopt($ch, CURLOPT_SSLVERSION, 1);
curl_setopt($ch, CURLOPT_URL, "$unifiServer");
curl_setopt($ch, CURLOPT_POSTFIELDS, "accept-tou=yes");
$return = curl_exec ($ch);
curl_close ($ch);

ticket: 131319)

Привет,

@ordos,

К сожалению, в контроллере или точках доступа на v3.2.5 исправления нет. Фикс находится в коде образцового портала, как я и объяснял. Если после адаптации к новому коду образцового портала у вас все еще возникают проблемы, пожалуйста, откройте заявку в Zendesk и предоставьте код вашего портала и резервную копию файла для рассмотрения.

Спасибо,
DavidQ.

Привет, Дерек,

В версии 3.2.5 программного обеспечения нет исправления для этой проблемы. В некоторых случаях решение — обновить до нового кода из образцового портала с ap_mac, как ты и указал. Мы с удовольствием рассмотрим твой внешний портальный код. Пожалуйста, открой тикет и прикрепи свой портальный код вместе с файлом резервной копии, чтобы мы могли помочь тебе в его рассмотрении. Добавь номер тикета здесь, чтобы я мог сопоставить тикет с тобой.

Спасибо,
DavidQ.

Привет,

@UBNT-DavidQ,

...просто из любопытства, была ли реальная причина вызывать shell-скрипт для выполнения curl-запросов вместо использования соответствующих PHP curl-функций?

Привет, DavidQ! Я создал заявку, номер 123755, но немного застрял. Было бы неплохо, если бы её немного продвинули. Код пока не загружал. Пока всё, Jason.

Привет, Джейсон!

1. Есть ли эта функциональность реально в API на 3.2.1?
  ==> Да, уже есть в 3.2.1. Это только для внешнего портала.

2. Означает ли использование ap_mac, что гость *только* аутентифицирован к этому конкретному AP?
  ==> Нет. Аутентификация происходит на уровне контроллера. Сначала должно произойти взаимодействие для получения информации (авторизация с вашего внешнего портала обратно на контроллер). Если мы используем обычный метод inform, то время меняется с увеличением количества AP, что вызывает задержку (что видели несколько человек). Но с AP_mac это обходит inform (и его задержку) и идет напрямую на AP.

Было бы хорошо, если бы вы открыли заявку через нашу поддержку по электронной почте и загрузили туда код вашего внешнего портала и ваш резервный файл. Затем укажите номер вашей заявки здесь, чтобы я мог посмотреть вашу заявку и проверить ваш код.

Спасибо,
Дэвид
Q.