Не удаётся подключиться к Cloud Key "using Cloud", зависает на этапе "Запрос SDP..."

Не удаётся подключиться к Cloud Key "using Cloud", зависает на этапе "Запрос SDP...", UniFi Network

Clam-

Guest

30.01.2017 05:23:00

Привет! Не могу подключиться к нашему Cloud Key удалённо «через Cloud» (по WebRTC). Локально, когда я на месте, могу подключиться «по IP контроллера», но даже на месте через WebRTC тоже не получается. Я уже создал тикет #607239, если кто из ubnt захочет посмотреть или если кому-то ещё пригодится этот тикет для похожих проблем.

Скоро придется переходить к более решительным мерам, чтобы снова подключиться к Cloud Key удалённо, например, перезагрузить его, но перед этим хотел узнать, нужна ли какая-то дополнительная информация для отладки, которая могла бы помочь понять, в чём проблема.

Недавно (на прошлой неделе) обновился до 5.4.9. На unifi.ubnt.com устройство отображается как «online». Пробовал Firefox и Chrome, включая режим инкогнито, но без результата. У меня EdgeRouter lite3 и UniFi Switch PoE 16. Правила файрвола на роутере не менялись уже несколько месяцев, и общий исходящий трафик не фильтруется.

Обновление делал удалённо по WebRTC, после обновления в течение нескольких дней подключение работало.

Некоторые данные об устройстве:
----------
ИНФОРМАЦИЯ О СЕРВЕРЕ
Текущая версия 5.4.9 (Build: atag_5.4.9_9150)
ФИРМВЭР CLOUD KEY
Текущая версия UCK.mtk7623.v0.5.9.6794855.161129.1409
CLOUD KEY CONTROLLER
Текущая версия 5.4.9-9150
ВЕРСИЯ КОНТРОЛЛЕРА
UI 5.4.9.1
Backend 5.4.9 Buildatag_5.4.9_9150
Доступ к облаку Включён
----------

Спасибо за внимание.
(Заголовок отредактировал.)

DTC57 Guest	#2 29.01.2018 12:04:00 Пожалуйста, пришлите мне команду для перезапуска сервиса — я так понимаю, это можно сделать через SSH... Спасибо ещё раз, Дэвид.

UBNTAeroNotix

Guest

29.01.2018 11:52:00

@DTC57

У меня есть всё, что нужно из этого файла журнала. Ты можешь перезапустить службу unifi на UCK, чтобы всё заработало снова. Мы разбираемся с коренной причиной проблемы и свяжемся с тобой, как только у нас появятся новости.

DTC57 Guest	#4 29.01.2018 07:36:00 CloudKey питается через PoE. Я хотел использовать USB-зарядку, которая сработала лишь один раз. По какой-то причине во второй раз он не включился — видимо, UCK требует довольно много энергии.

DTC57 Guest	#5 29.01.2018 06:38:00 Отправляю тебе (Аарон) файл по электронной почте

kuoh

Guest

29.01.2018 19:24:00

Ты можешь также проверить корневую папку на наличие файла server.stop или чего-то с похожим именем. Я помню, что сталкивался с одним из наших CK, который не запускал контроллер именно из-за такого файла — скорее всего, это была какая-то процедура восстановления после ошибки, чтобы не допустить бесконечного цикла перезагрузок CK. KuoH

rickatbbswork

Guest

13.09.2019 01:23:00

У меня две сети. Обе находятся ниже по уровню от другой сети. В моей церкви есть кабельный модем, и unifi получает IP-адрес из диапазона 192.168.31.1/24. У моего фестиваля оптоволоконное подключение, и я строил его в лаборатории, там тоже был приватный адрес из офиса. Если мне нужно перезагрузить сеть, я всегда одновременно выключаю USG и Cloud Key и включаю их обратно вместе (через сетевой фильтр). Проходит несколько часов, прежде чем я смогу подключиться к контроллеру удалённо. В церкви я просто заходил в контроллер и перезагружал коммутатор и USG — около 5 минут не мог попасть в сеть. Сеть фестиваля перезагрузили примерно 5 часов назад, и я до сих пор не могу её увидеть или управлять ей.

Necronaut

Guest

17.02.2019 17:30:00

Столкнулся с похожими проблемами, как здесь описано. Использую USG + UniFi Switch 8 POE-60W + AC AP Pro и Cloud Key. Модем/роутер провайдера настроен в режиме моста и подключён к WAN-порту USG. Других проблем нет, кроме того, что не могу подключиться к Cloud Key Controller через портал UniFi Cloud Access.

Как только я перезагружаю или делаю сброс на заводские настройки с последующим восстановлением резервной копии на Cloud Key, подключение через портал снова работает. Но через несколько минут появляется ошибка 400 в Chrome/Firefox и какая-то ошибка с "SDP" в приложении для iOS. Состояние то переключается на онлайн в портале без отображения версии прошивки, то полностью уходит в офлайн. Когда версия прошивки отображается, значит он работает. Но стабильности ноль, и я уже боюсь, что что-то случится, когда я буду не на месте и не смогу это исправить.

Обращался в техподдержку через чат — меня попросили запустить .js-скрипт для восстановления базы данных после остановки службы UniFi и затем её запуска обратно. После этого система работала чуть дольше, чем после сброса, но со временем проблема повторилась.

Техподдержка также посоветовала попробовать запитать Cloud Key через USB-C, но у меня нет блока питания для USB-C. Можно ли попробовать PoE-инжектор, который шел с UniFi AP-AC-Pro? Не очень понял смысл, но сказали, что свитч выдаёт 48В, а CK нужно всего 5В. Сейчас у меня UniFi Switch 8 POE-60W питает CK и AP, а к свитчу ещё подключены три других устройства без PoE.

Cloud Key работает на прошивке v0.13.4 и контроллере v5.10.17-11638-1.

Есть идеи, что происходит и что можно сделать? Стоит ли просто вернуть CK продавцу и заказать новый? Купил всего пару дней назад, есть 30-дневная возможность возврата.

Если не было понятно — контроллер на CK всегда доступен локально, пока эта проблема происходит, но удалённый доступ через облако был именно той причиной, по которой я и купил Cloud Key.

С уважением.

cloudbustersinc

Guest

25.09.2018 01:09:00

У нас есть клиенты, которых мы сейчас подключаем к системе Unifi. Всего планируется добавить 100 устройств в течение следующего года. Проблема в том, что после того, как первое устройство без проблем заработало, система начала зависать на стадии Requesting SDP. Система работает нормально 4–5 часов, показывает статус онлайн, текущую версию ПО 2.8.30, но потом просто останавливается на SDP. На месте всё работает отлично, но запустить её снова не получается. Клиент подключил к сети систему Vivint примерно за 15 минут до возникновения проблемы. Даже после её отключения проблема осталась. Может, кто-то сможет помочь или подскажет, что делать? С уважением,

Smarthomes Guest	#10 13.09.2018 15:03:00 PM отправлено

UI-Team Guest	#11 12.09.2018 01:28:00 Привет, @Smarthomes Спасибо за уведомление. Я отправил вам сообщение, чтобы узнать побольше подробностей по этому поводу. Спасибо, Дэвид С.

BengalTiger

Guest

#12

12.09.2018 01:28:00

Я в целом уже практически смирился с этим.
1. Firefox/IE: ни в коем случае не пользуйтесь. Они не могут обеспечить стабильное соединение.
2. Chrome: да, но время от времени у меня всё равно возникает та же ошибка.
3. Что ещё хуже — после открытия в новом окне или вкладке через пару минут появляется ошибка 400. Теперь я привык просто закрывать окно или вкладку и запускать заново.

DTC57

Guest

#13

29.01.2018 19:12:00

К вашему сведению, просто перезагрузка таким способом не помогла. Я также пробовал «/etc/init.d/unifi stop», а затем «/etc/init.d/unifi start». Без результата. Сейчас спущусь в подвал и выключу питание полностью, чтобы перезагрузить устройство — посмотрим, поможет ли. Если нет, то придется снова делать полный сброс ;-(

Smarthomes

Guest

#14

12.09.2018 01:19:00

У нас такая же проблема. Мы сами хостили около 280 сайтов на intel nuc в офисе. Сам контроллер работал идеально, но мои техники сталкивались с трудностями при подключении к контроллеру через Unifi Cloud Service, находясь в полевых условиях. Единственным решением было перезагрузить контроллер... это временно решало проблему, но потом подключение снова переставало работать. Недавно мы решили перенести контроллер вне офиса, используя виртуальную машину на Ubuntu. Проблемы с подключением остались, но теперь всё происходит гораздо быстрее. Через день работы уже невозможно подключиться через облачные сервисы. Система показывает, что онлайн, но при попытке подключения зависает на «Requesting SDP...» Я могу подключиться к контроллеру напрямую по внешнему IP виртуальной машины без всяких проблем. Есть идеи?

DTC57

Guest

#15

08.09.2018 07:55:00

Я перешёл на серверное решение и таким образом избавился от CloudKey. Хорошая новость в том, что сейчас Ubiquiti предлагает новое поколение Cloud Key, которое, как утверждается, решает проблему с повреждением базы данных — именно она, судя по всему, была корнем всех этих проблем. Мой единственный совет: регулярно делайте актуальные резервные копии конфигурации и будьте готовы восстановить их, если Cloud Key первого поколения начнёт сбоить. Удачи! D

tangledcord Guest	#16 08.09.2018 02:16:00 Начало происходить у меня сегодня вечером.

rthomas75

Guest

#17

29.08.2018 02:48:00

Прошло уже некоторое время с момента публикации этого поста, и у меня та же самая проблема. Шесть дней назад я установил новую сеть (моя первая установка Ubiquiti) в многомиллионном доме клиента, и всё прошло отлично. Я установил Security Gateway Pro, коммутатор US-24-250W, 5 точек доступа UAP-AC-HD и Cloud Key. Сеть очень простая — статический IP (через Comcast) и 2 открытых порта. Сегодня утром я проснулся и не смог подключиться через Cloud Key (ни с компьютера, ни через приложение на iPhone). Соединение зависает на «Requesting SDP offer.» Сегодня я связался с техподдержкой. Они велели перезагрузить Cloud Key, и всё сразу заработало отлично. Я выразил опасения, что это может повториться, ведь я конечно не живу на объекте и не хочу постоянно перезагружать ключ. Ещё они попросили зайти на test.webrtc.org, чтобы проверить, как работает webrtc. Всё вроде в порядке. Короче, спустя 6 часов та же ошибка. Я не могу подключиться, что бы ни пробовал. Прикрепил отчёты и фото. Помогите, пожалуйста!

DTC57 Guest	#18 30.01.2018 21:33:00 Я удалил /server.stop. Посмотрим, что из этого выйдет!

kuoh

Guest

#19

29.01.2018 23:03:00

CK, с которым я столкнулся, не запускал контроллер Unifi, если файл server.stop был на месте, поэтому мне пришлось его удалить. Похоже, у тебя сейчас всё работает после сброса к заводским настройкам, но такого файла не бывает на корректно работающем CK, так что я не вижу проблем в его удалении. Ещё стоит проверить использование диска. Я встречал CK, на которых лежали старые резервные копии с разных обновлений контроллера — из-за этого диск был заполнен на 90% и более, и чтобы всё заработало нормально, пришлось всё вручную почистить. KuoH

DTC57 Guest	#20 29.01.2018 20:49:00 В конце концов единственным решением стало сделать сброс к заводским настройкам и восстановить резервную копию. У меня такая ситуация была на Рождественских каникулах, и в итоге мне пришлось заново настраивать всю сеть с нуля. Теперь я чуть мудрее и делаю гораздо больше резервных копий. Тем не менее, сейчас я не уверен, что моя сеть сможет нормально пережить отключение питания. Хорошая новость — она только что выжила после мягкой перезагрузки. Интересно, что сегодняшняя резервная копия оказалась примерно в два раза меньше предыдущей — может, файл резервной копии не должен быть слишком большим? Этот вид сбоев стал одной из причин покупки нового CloudKey, который пока что работает не очень удачно — теперь у меня два CloudKey, и оба сломались, повредившись. ;-( Я также купил внешний аккумулятор 2A USB и USB-кабель с целью запитать CloudKey автономно (как кто-то советовал на форуме), но это вообще не срабатывает — устройство даже не перезагружается при питании через USB (( Так что сейчас, если CloudKey сломается, мне ничего не остается, кроме как пройти весь этот процесс заново, используя последнюю резервную копию. К сожалению, второй CloudKey не помогает, потому что ему присваивается другой IP-адрес, и он просто не может взять на себя управление устройствами. Можно попасть в ситуацию с неподключенными устройствами, которые нельзя просто перенять, и без боли вернуться к рабочей конфигурации не получится. Кстати, в корневой папке есть файл server.stop. Его действительно нужно удалять? Ведь я же только что сделал полный сброс настроек... Сейчас собираюсь выключить CloudKey и запустить его "с нуля". Если это сработает — буду немного спокойнее. Похоже, он успешно перезагрузился с холодного старта — УФ!

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