Редактировать: 19.04.2022 — добавлены несколько логов с воспроизведённой проблемой на версии 6.0.18.
Редактировать: 30.03.2022 — добавлена информация для @UI-Glenn.
1) Топология: На экране топологии ничего не отображается из-за следующей ошибки в прошивке:
Скриншот топологии ниже был сделан на более старой версии прошивки (5.4x). Топология точная, только местами поменялись AP1 и AP5 — AP1 теперь в офисе, AP5 — в гостевой комнате. Маршрутизатор Unifi и коммутаторы Unifi не используются, только точки доступа.
---
2) Информация об установке: Этот скриншот, наверное, лучше всего объясняет:
Используется роутер Comcast XB7. Все Ethernet-коммутаторы — неуправляемые. Из точек доступа в проводе — только две: AP1 в офисе и AP2 в домашнем кинотеатре. Все AP — NanoHD, кроме AP6 в гараже, который U6-Lite.
AP1 (NanoHD, проводной) <--> AP3 (NanoHD, беспроводной) <--> AP4 (NanoHD, беспроводной) <--> AP6 (U6-Lite, беспроводной)
AP2 (NanoHD, проводной) <--> AP5 (NanoHD, беспроводной)
Информация по 5 ГГц: Все 5 NanoHD работают в режиме VHT160. AP1 — канал 50, AP2 — канал 114, AP3/AP4/AP5 – выбор канала авто. AP6 (U6-Lite) работает в HE80, канал авто. Проблем с переходом U6-Lite в 30-минутный режим ожидания на любой прошивке нет, проблема только у NanoHD.
---
3) Тест-кейс. Важно: для воспроизведения проблемы нужно несколько AP. 2 NanoHD — недостаточно, чтобы вызвать баг. Для проблемы нужно 5 NanoHD. Я не проверял с 3 или 4 NanoHD.
a) Начинаем с 5 NanoHD на прошивке 5.60.23
b) Запускаем непрерывный ping ко всем 5 NanoHD (IP прописаны статически через DHCP)
c) Прошиваем все 5 NanoHD до версий 6.0.14 или 6.0.15. Сначала downlinks, затем uplinks, например, в порядке AP4, AP5, AP3, AP1, AP2.
d) Уже после шага c AP3/AP4/AP5 могут уйти в режим ожидания на 30 минут — это видно по отсутствию ответов на ping, запущенный на шаге b.
e) Если баг не сработал сразу, повторяем ниже (начиная с f).
f) Переходим в Legacy UI и открываем экран Devices, чтобы появилась колонка «actions».
g) Перезапускаем все APы с интервалом в несколько секунд — сначала downlinks, потом uplinks, через кнопку «restart» в колонке actions, например, в том же порядке: AP4, AP5, AP3, AP1, AP2.
h) Ждём 5 минут, пока все AP перегрузятся. AP1 и AP2 вернутся примерно за 3 минуты — это видно по пингам. Некоторые или все AP3/AP4/AP5 уйдут в 30-минутный режим ожидания. При этом не будет никаких радарных оповещений, даже когда все AP снова выйдут в онлайн.
i) Повторяем шаги f/g/h для воспроизведения проблемы.
---
Оригинальный пост:
Появилась новая прошивка 6.0.14 для моих 5 NanoHD и одного U6-Lite. Вчера вечером обновил вручную. Две точки доступа проводные, четыре — беспроводные. Сначала обновил беспроводные, потом проводные.
Все AP мониторятся через smokeping. На скриншоте видно, что одна из беспроводных downlinks, NanoHD, после обновления сначала «падала» на несколько минут — это нормально.
Но когда обновлял прошивку на uplink (проводной, тоже NanoHD), downlink лежала около получаса. Я не понимаю, почему это занимает столько времени. Как только точка видит, что uplink пропал, она ведь должна начать его искать или искать другой uplink, который в доме был доступен, но к которому она тоже не подключилась.
30 минут простоя — это вообще ни в какие ворота.
То же самое происходит, если вручную перезагрузить uplink AP по любой другой причине, кроме прошивки.
Это не новое ухудшение. Исправят ли когда-нибудь?
Кстати, проблема проявляется только на двух беспроводных downlink, обе — NanoHD. Другие две (одна NanoHD, одна U6-Lite) такой проблемы не показывали, быстро переподключались — в течение нескольких минут — либо к тому же uplink, либо к другому.
Редактировать: 30.03.2022 — добавлена информация для @UI-Glenn.
1) Топология: На экране топологии ничего не отображается из-за следующей ошибки в прошивке:
Скриншот топологии ниже был сделан на более старой версии прошивки (5.4x). Топология точная, только местами поменялись AP1 и AP5 — AP1 теперь в офисе, AP5 — в гостевой комнате. Маршрутизатор Unifi и коммутаторы Unifi не используются, только точки доступа.
---
2) Информация об установке: Этот скриншот, наверное, лучше всего объясняет:
Используется роутер Comcast XB7. Все Ethernet-коммутаторы — неуправляемые. Из точек доступа в проводе — только две: AP1 в офисе и AP2 в домашнем кинотеатре. Все AP — NanoHD, кроме AP6 в гараже, который U6-Lite.
AP1 (NanoHD, проводной) <--> AP3 (NanoHD, беспроводной) <--> AP4 (NanoHD, беспроводной) <--> AP6 (U6-Lite, беспроводной)
AP2 (NanoHD, проводной) <--> AP5 (NanoHD, беспроводной)
Информация по 5 ГГц: Все 5 NanoHD работают в режиме VHT160. AP1 — канал 50, AP2 — канал 114, AP3/AP4/AP5 – выбор канала авто. AP6 (U6-Lite) работает в HE80, канал авто. Проблем с переходом U6-Lite в 30-минутный режим ожидания на любой прошивке нет, проблема только у NanoHD.
---
3) Тест-кейс. Важно: для воспроизведения проблемы нужно несколько AP. 2 NanoHD — недостаточно, чтобы вызвать баг. Для проблемы нужно 5 NanoHD. Я не проверял с 3 или 4 NanoHD.
a) Начинаем с 5 NanoHD на прошивке 5.60.23
b) Запускаем непрерывный ping ко всем 5 NanoHD (IP прописаны статически через DHCP)
c) Прошиваем все 5 NanoHD до версий 6.0.14 или 6.0.15. Сначала downlinks, затем uplinks, например, в порядке AP4, AP5, AP3, AP1, AP2.
d) Уже после шага c AP3/AP4/AP5 могут уйти в режим ожидания на 30 минут — это видно по отсутствию ответов на ping, запущенный на шаге b.
e) Если баг не сработал сразу, повторяем ниже (начиная с f).
f) Переходим в Legacy UI и открываем экран Devices, чтобы появилась колонка «actions».
g) Перезапускаем все APы с интервалом в несколько секунд — сначала downlinks, потом uplinks, через кнопку «restart» в колонке actions, например, в том же порядке: AP4, AP5, AP3, AP1, AP2.
h) Ждём 5 минут, пока все AP перегрузятся. AP1 и AP2 вернутся примерно за 3 минуты — это видно по пингам. Некоторые или все AP3/AP4/AP5 уйдут в 30-минутный режим ожидания. При этом не будет никаких радарных оповещений, даже когда все AP снова выйдут в онлайн.
i) Повторяем шаги f/g/h для воспроизведения проблемы.
---
Оригинальный пост:
Появилась новая прошивка 6.0.14 для моих 5 NanoHD и одного U6-Lite. Вчера вечером обновил вручную. Две точки доступа проводные, четыре — беспроводные. Сначала обновил беспроводные, потом проводные.
Все AP мониторятся через smokeping. На скриншоте видно, что одна из беспроводных downlinks, NanoHD, после обновления сначала «падала» на несколько минут — это нормально.
Но когда обновлял прошивку на uplink (проводной, тоже NanoHD), downlink лежала около получаса. Я не понимаю, почему это занимает столько времени. Как только точка видит, что uplink пропал, она ведь должна начать его искать или искать другой uplink, который в доме был доступен, но к которому она тоже не подключилась.
30 минут простоя — это вообще ни в какие ворота.
То же самое происходит, если вручную перезагрузить uplink AP по любой другой причине, кроме прошивки.
Это не новое ухудшение. Исправят ли когда-нибудь?
Кстати, проблема проявляется только на двух беспроводных downlink, обе — NanoHD. Другие две (одна NanoHD, одна U6-Lite) такой проблемы не показывали, быстро переподключались — в течение нескольких минут — либо к тому же uplink, либо к другому.