Каталог Поиск 0 Сравнить 0 Закладки 0 Корзина Войти
Каталог
105082, Москва, ул. Фридриха Энгельса, 75с21, БЦ Бауманский ИТКОЛ
Пн - Пт: с 09-00 до 18-00 Сб: с 10-00 до 18-00 Вс: выходной
Страницы: 1
RSS
AP зависает на стадии принятия/настройки., UniFi Network
 
Это мой самый первый Unifi AP. После получения я сразу настроил его в нашей локальной сети для теста, и он работал безупречно. Железо отличное. Версия прошивки 2.2.3, и точная такая же прошивка стоит на AP, обновление происходит автоматически. Единственное — мой начальник, который очень заботится о безопасности, хочет, чтобы устройство работало в нашей DMZ, так же, как и Wi-Fi решение, которое оно заменяет, а не в локальной сети... и вот с этого момента начались проблемы. (К тому же он хочет настраивать защиту с помощью белого списка MAC-адресов, но, похоже, контроллер этого пока не поддерживает — но это уже другая история.)

У нас в DMZ есть небольшой диапазон IP-адресов (контролируется роутером SonicWALL Pro 2040). Я использую DHCP роутера, который раздает адреса из этого диапазона, и и AP, и контроллер (чисто установленный UniFi контроллер на ноутбуке с отключённым брандмауэром Windows) получают IP именно от роутера. UniFi Discover видит AP и его IP. Контроллер пингует AP и может к нему подключиться через SSH. AP тоже пингует контроллер.

Конечно, unifi:8080 не резолвится на правильный адрес, так как в нашей DMZ нет настраиваемого DNS-сервера. Я установил адрес inform через Discover и через ssh (mca-cli, set-inform и т.п.), и в логах сообщений (tail -f /var/log/messages) видно, что сначала он пытался соединиться с нужным IP, а потом почему-то возвращался к unifi:8080 (что раздражает — если попытка не удалась с первого раза, он, похоже, просто сбрасывает заданный вами адрес).

Я поправил файл /etc/hosts на AP, чтобы unifi всегда резолвился в IP контроллера ноутбука. Теперь вместо подвешенного состояния «adopting» в софте контроллера он чаще показывает «provisioning», иногда прыгает на «disconnected», потом снова «adopting», и застревает на «provisioning» ещё на какое-то время.

В логах видно, что AP вроде как принимает, но связь потом прерывается по тайм-ауту и теряется, и он снова начинает вещать, как будто ищет возможность подключения.

Есть идеи?
 
Можешь подробнее объяснить? Когда устройство застревает в режиме настройки, оно постоянно прерывает трансляцию своего SSID.
 
Как насчёт продолжить быть AP и раздавать WiFi?
 
А если она не ответит сразу, что тогда?
 
Спасибо за список портов. В моём случае хватило открыть TCP 8080 и UDP 3478.
 
Пожалуйста, вставьте текст, который нужно перевести.
 
Привет! Будучи новым пользователем UniFi, я столкнулся с такой проблемой у себя дома. У меня есть cloud key и 3 точки доступа. AP 1 постоянно застревал в состоянии провиженинга. Обновление и перезагрузка cloud key сразу выводили AP из этого состояния.

Чтобы предложить возможное решение — как насчёт дать точкам доступа больше автономии? Если обновление не удаётся или cloud key работает нестабильно, вернуть AP (или cloud key) к предыдущему, предположительно рабочему состоянию, отправить необходимые уведомления в логи администратора и продолжать раздавать WiFi.

Как ты и заметил, текущая конфигурация отключает радиомодули точки доступа.
 
Я знаю, что это старое обсуждение, но у меня была такая же проблема, и именно этот пост первым выдал поисковик. Я запускаю контроллер на Raspberry Pi... после долгих попыток понять, почему точки доступа застряли в статусе provisioning, я перезапустил контроллер с помощью команды /etc/init.d/unifi restart. После этого мои точки доступа сразу же заработали. Меня немного беспокоит, что при проблемах с контроллером точки доступа перестают работать. Кажется, они должны иметь хотя бы какую-то автономную работу, например, использовать «последние рабочие настройки, если не могут связаться с контроллером» или что-то в этом роде.
Страницы: 1
Читают тему (гостей: 1)