Радиоприемники отключены — невозможно включить.

Радиоприемники отключены — невозможно включить., UniFi Network

dbrewer

Guest

26.09.2017 11:45:00

Привет! У меня проблема: на некоторых точках доступа в контроллере показываются отключённые радио (красным на изображениях), хотя настройки у них точно такие же, как у другой точки доступа, которая работает нормально (зелёным на изображениях). Даже известная рабочая точка доступа с другого объекта при сбросе и привязке к контроллеру отображается как отключённая. Я не могу понять и решить эту проблему. Сброс и повторная привязка помогли с двумя точками, но с остальными — нет. Есть ли другой способ включить радио, возможно через SSH? Заранее спасибо за помощь. Даррен.

Shred

Guest

10.10.2017 16:30:00

У меня внезапно возникла такая проблема. Домашняя сеть с одним UniFi AP-AC-Pro, прошивка v3.8.14.6780. Вдруг я потерял все беспроводные устройства. Контроллер UniFi (v5.5.20) показывал, что радиомодули неактивны (серые), и не было возможности их включить. В интерфейсе отображалось, что радиомодули «Включены на этом AP». Журнал событий UniFi не показывал ничего странного — всё было нормально, а потом вдруг пошли записи о том, что каждый Wi-Fi клиент отключается от SSID.

Перезапуск через контроллер UniFi восстанавливал доступ к Wi-Fi примерно на минуту, потом радиомодули снова отключались (сначала 2.4 ГГц, чуть позже 5.8 ГГц). Отключение и повторное подключение к PoE свитчу давало такой же эффект: сеть возвращалась на минуту, затем выключалась снова.

Пробовал переустановить текущую прошивку — не помогло. Обновил контроллер с 5.5.20 до 5.5.24 — тоже без изменений. Живу в полу-сельской местности, так что помех быть не должно, но всё равно сменил каналы — безрезультатно.

Перезагружал AP, затем сразу же выключал контроллер UniFi, чтобы исключить команду на отключение радиомодулей — не спасло. Пытался сделать «забыть это устройство» и сброс к заводским настройкам через SSH — тоже без результата.

В одном посте советовали сделать «compact database», но и это не помогло (маловероятно для такой небольшой сети, но решил попробовать): https://community.ui.com/questions/450d8959-78c0-4ec9-8c36-763a22670fea

Вот у этого парня похожие проблемы начались после обновления контроллера до v5.5.20: https://community.ui.com/questions/00c7ad44-cb58-422b-8975-f52fa2728be8

Есть какие-нибудь идеи?

SafeFleet

Guest

22.08.2018 12:39:00

Шанс найти это самому был равен нулю, спасибо! 😲 Что касается моей проблемы, вот как я её решил, не имея возможности напрямую зайти на WAPы:

1. Заставил UniFi забыть проблемные точки доступа и дождался завершения удаления.
2. Отключил PoE на всех проблемных UAPах.
3. Перезагрузил Cloud Key.
4. Несколько минут размышлял, не стоило ли просто купить побольше SonicPoints.
5. Заново вошёл в UniFi (на этот раз пароль сработал с первого раза, а не после двух попыток «забыл пароль», после чего всё равно принимал тот же самый).
6. Настроил пару других UAPов, а проблемные оставил висеть в таймауте. При настройке применял изменения по одному, а не все сразу: Alias, Channel, WLANs, Network, Firmware Update — именно в таком порядке.
7. Когда эти устройства применили настройки нормально, включил PoE на проблемных UAPах, и они показали статус «готовы к добавлению».
8. В итоге смог их нормально сконфигурировать, и они наконец-то удерживали радиомодули включёнными — как положено хорошим девайсам.

AndyWrightUK Guest	#4 21.08.2018 22:14:00 @SafeFleet Чтобы войти в устройство, используйте данные для входа, указанные в разделе Настройки, Сайт, Аутентификация устройства. Убедитесь, что SSH включен, пока вы там.

SafeFleet

Guest

21.08.2018 22:12:00

У меня такая же проблема при развёртывании новых UAP-AC-Pro. Первый поднялся нормально и к нему подключились клиенты, а вот следующие два? У одного отключены радиомодули, а второго вообще не видно в контроллере UniFi.

* Копирование конфигурации с первого работающего AP не решило проблему.
* Отключение автообновлений прошивки и принудительное обновление тоже не помогли.
* Скачал WinSCP, чтобы попробовать обновить локально, но даже не могу зайти — выдаёт ошибку «доступ запрещён» при тех же учётных данных, что и для UniFi контроллера. root/ubnt тоже не работают.

Похоже, теперь придётся сначала настраивать эти ребята, прежде чем вешать их под потолок. >.>

DirigoMan

Guest

25.04.2018 17:12:00

25.04.18 Сейчас я на месте установки, часть оборудования — 10 UAP-AC-M-PRO и 5 UAP-AC-PRO. Контроллер версии 5.6.22. У меня та же проблема с отключением, что и в предыдущих сообщениях. Вся техника Ubiquiti работает на последних версиях ПО. В итоге я обнаружил, что DHCP-диапазон, заданный в UniFi Security Gateway, не совпадал с тем, что ожидал контроллер. Как только они совпали, проблема с отключением исчезла.

CHTI

Guest

13.11.2017 10:01:00

У меня была такая же проблема с 2 из 5 UAP-PRO, которые я развернул на одном объекте. Вот простой и быстрый способ починить без SSH, который сработал у меня: скопировать конфигурацию с WAP, у которого радиомодули включены, на те, что велись некорректно — и вуаля! Радиомодули заработали, и всё снова в порядке.

Я не против использовать SSH, собственно. Просто не люблю доставать ноутбук, когда можно обойтись iPhone или iPad — стараюсь этого избегать. Копирование конфигурации с телефона через LTE сработало отлично.

Matt

Shred

Guest

10.10.2017 22:45:00

Отвечу на свой вопрос. Кратко: неисправный DHCP-сервер раздавал неверный адрес шлюза (7.0.0.0). Я не мог загрузить новую прошивку и не мог загрузить более раннюю версию прошивки AP. Ссылка от dbrewer помогла мне через scp залить на AP старую, проверенную версию прошивки... но проблема осталась, даже когда работал старый софт. Запись МайкаD в конце его поста «firmware... has been released» про необходимость NTP подсказала, в чем дело. AP не мог выйти в интернет, а время стояло «1 января 1970». NTP не срабатывал, потому что шлюз AP был 7.0.0.0 (назначенный через DHCP).

BZ.v3.9.2# route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
default 7.0.0.0 0.0.0.0 UG 0 0 0 br0
7.0.0.0 * 255.255.255.255 UH 0 0 0 br0
192.168.0.0 * 255.255.255.0 U 0 0 0 br0

DHCP-сервер — dnsmasq v2.72, работает на Debian Linux. Я редактировал конфиг, чтобы dnsmasq поддерживал новую VLAN. По какой-то причине dnsmasq не «понравился» адрес шлюза «192.168.00.254» (двойной ноль — проблема). Я не связывал это изменение в DHCP-сервере с неправильной работой AP, потому что ничего не менялось до тех пор, пока точка доступа не решила обновить DHCP-лиз примерно через двенадцать часов.

Вот проблемный участок dhsmasq.conf:
dhcp-option=subnet0,3,192.168.00.254
dhcp-option=subnet1,3,192.168.10.1
dhcp-option=subnet2,3,192.168.30.1

Изменение «192.168.00.254» обратно на «192.168.0.254» решило проблему. Проверка «ipconfig» на Windows-машине тоже показала похожую странность, так что, похоже, проблема была в dnsmasq, а не в Ubiquiti AP.

Shred

Guest

10.10.2017 19:47:00

Хмм... выглядит многообещающе: Изменения в прошивке с версии 3.9.1:
[UAPG3] Улучшена коммуникация между VLAN.
[UAPG3] Исправлено ложное обнаружение rogue AP.
[UAP] Исправлена утечка памяти, которая возникала при некоторых конфигурациях.
[UAP] Различные исправления и улучшения внутренней работы.
[SEC] Обновлён dnsmasq до версии 2.78.
https://community.ui.com/releases/bfe3982b-166f-455a-8c91-eb56fcae38ac

dbrewer Guest	#10 10.10.2017 16:39:00 Скачайте последнюю прошивку для этой точки доступа с сайта UniFi. Когда загрузите, переименуйте файл в FWupdate.bin и выполните шаги по локальному обновлению прошивки по ссылке ниже. Для этого вам понадобятся программы WinSCP и PuTTY, установленные на вашем Windows ПК. https://community.ui.com/questions/82d86374-e879-476f-b423-b1b29892f862#comment/0374c9b4-5bc9-4595-8f0a-adcea2b26c72 Надеюсь, это поможет.

Читают тему (гостей: 1)