USG завис в режиме «Provisioning».

USG завис в режиме «Provisioning»., UniFi Network

Braadpap

Guest

20.10.2016 11:28:00

Всем привет,
недавно я установил USG вместе с контроллером Unifi (запущенным на Rpi2), и после первоначальной настройки (принятия устройства и обновления) через контроллер, устройство показало статус «Connected». Через час оно перешло в режим Provisioning, из-за чего я не мог смотреть статистику, хотя интернет при этом продолжал работать.
Сегодня утром, когда я проверял контроллер, там снова было «Connected», но спустя два часа устройство снова перешло в режим Provisioning.
Контроллер Unifi работает на версии 5.2.9, а USG — на 4.3.23.4913544.
Подскажите, поможет ли установка бета-версии прошивки решить эту довольно раздражающую проблему?
Заранее спасибо.

chal086 Guest	#2 11.02.2017 17:41:00 У меня такая же проблема, и я просто создал новую тему, так как эта была отмечена как решённая; https://community.ui.com/questions/65cdc67f-76ba-4fae-9de2-16dc605aabd0 Спасибо.

pknokey

Guest

02.11.2017 23:19:00

И мой USG, и точка доступа постоянно застревали в цикле подключения. Я просто подключился к каждому через SSH и ввёл команду
set-inform http://controller_IP:8080/inform — после этого оба сразу же получили настройки и больше не сбоили. Ничего сложного, просто они искали контроллер в другом месте.

hotdogs

Guest

16.10.2017 18:59:00

Мой USG застрял в режиме настройки. Не связывайтесь с техподдержкой в чате — они только все усложняют. Я могу перезагружать оба устройства удалённо, но это не помогает. Завтра приедет грузовик с новыми деталями. Какой толк в удалённом доступе, если он ничего не исправляет?

ush-132

Guest

29.06.2017 14:19:00

Также была прошивка USG 4.3.41 с контроллером 5.4.18, которые застряли в режиме «provisioning». Немного поэкспериментировал с обновлением USG и контроллера на разные версии — результата ноль. Потом у меня возникло подозрение, что дело в кастомной настройке в config.gateway.json. Удалил раздел «VPN», перезапустил контроллер — и USG перешёл в режим «connected».

Vanderbeek

Guest

14.02.2017 20:08:00

У меня была похожая проблема: USG застрял в режиме "Provisioning" почти на весь час, за исключением нескольких минут. Также заметил, что на Cloud Key мигал белый свет вместо синего. Вот шаги, которые я сделал, и которые помогли решить проблему в нашей сети:

1) отключил Cloud Key от коммутатора
2) отсоединил блок питания от USG
3) отключил коммутатор и кабельный модем от USG
4) подключил блок питания обратно к USG
5) подождал несколько минут — индикатор USG перестал мигать и загорелся ровным синим светом
6) подключил обратно коммутатор и кабельный модем к USG
7) подождал несколько минут — всё вернулось в норму
8) подождал еще несколько минут, чтобы убедиться, что проблема не повторится
9) подключил Cloud Key обратно к коммутатору
10) подождал несколько минут — индикатор Cloud Key тоже загорелся ровным синим светом
11) нормальная работа продолжилась.

j1engineering

Guest

19.03.2017 05:42:00

Наткнулся на ещё один сценарий бесконечного провижинга: добавление неверного секрета конфигурации OpenVPN приводит к следующему в логе:

Mar 19 11:17:29 ubnt mcad: mca-edgemax._edgemax_parse_set_commit_save_results(): [commit error] ▒[ interfaces openvpn vtun64 ]
Mar 19 11:17:29 ubnt mcad: mca-edgemax._edgemax_parse_set_commit_save_results(): [commit error] Ошибка конфигурации OpenVPN: указанный файл shared-secret-key "/config/auth/BLANKEDOUT" недействителен.
Mar 19 11:17:29 ubnt mcad: mca-edgemax._edgemax_parse_set_commit_save_results(): [commit error] ▒0
Mar 19 11:17:29 ubnt mcad: mca-edgemax._edgemax_parse_set_commit_save_results(): [commit error] Коммит не удался
Mar 19 11:17:29 ubnt mcad: mca-edgemax._edgemax_parse_set_commit_save_results(): [delete] неудачно: 0 успешно: 1
Mar 19 11:17:29 ubnt mcad: mca-edgemax._edgemax_parse_set_commit_save_results(): [set] неудачно: 0 успешно: 1
Mar 19 11:17:29 ubnt mcad: mca-edgemax._edgemax_parse_set_commit_save_results(): [commit] неудачно: 1 успешно: 1
Mar 19 11:17:30 ubnt mcad: ace_reporter.reporter_handle_response(): edgemax apply config не удался (код ошибки: 4)
Mar 19 11:17:30 ubnt mcad: ace_reporter.reporter_handle_response(): ошибки коммита, {"COMMIT": {"error": "▒[ interfaces openvpn vtun64 ]\nОшибка конфигурации OpenVPN: указанный файл shared-secret-key \"/config/auth/BLANKEDOUT\" недействителен.\n\n▒0\nКоммит не удался\n", "failure": "1", "success": "1"}, "DELETE": {"failure": "0", "success": "1"}, "SESSION_ID": "BLANKEDOUT", "SET": {"failure": "0", "success": "1"}}#012

Это приводит к тому, что процесс провижинга никогда не заканчивается. Проблема решается удалением конфигурации OpenVPN; через минуту происходит мгновенный провижинг.

Mar 19 11:19:27 ubnt shutdown[9852]: выключение для перезагрузки системы
Mar 19 11:19:28 ubnt mcad: mca-edgemax-api.edgemax_do_service(): нет ответа в течение 900,00 секунд

UI-Team Guest	#8 19.02.2017 09:19:00 Причина этого и способ обхода указаны в этом посте. https://community.ui.com/questions/98ff7632-121a-4274-ad14-d49aac6d9c8a#comment/d77b8fbf-93d8-4f7d-8522-5d2e1590e50b

fiannuzz

Guest

18.02.2017 22:15:00

Вчера вечером я заметил, что устройство застряло на статусе «provisioning» и решил подождать, вдруг само продолжит работать, но, похоже, USG всё ещё даёт сбои. Сегодня днём я полностью потерял интернет-соединение. Попытался подключиться к локальной сети через Ethernet, но DHCP тоже не отвечал. В приложении Unifi CK тоже показывался как офлайн. На этот раз я перезагрузил только USG, и это восстановило связь — теперь статус «connected». Я посмотрел логи и вот что нашёл. USG ведёт себя очень нестабильно.

@UBNT-cmb

Какие-то рекомендации? Вы сталкивались с таким в своей лаборатории? Что делать?

[2017-02-18 13:45:58,454] <inform-21> ERROR dev - [commit errors] dev[f0:9f:c2:12:d6:ab], { "DELETE" : { "failure" : "0" , "success" : "1"} , "SESSION_ID" : "630270e15638c582e0b878e180" , "SET" : { "error" : { "port-forward lan-interface " : "Invalid interface name\n\nValue validation failed\n"} , "failure" : "1" , "success" : "1"}}
[2017-02-18 13:49:58,226] <WsPing> WARN websocket - consecutive ping loss. closing
[2017-02-18 13:49:58,243] <WsPing> INFO websocket - Cloud websocket connection closed: 1001
[2017-02-18 13:50:10,276] <Ws> ERROR websocket - error: java.net.UnknownHostException: device.svc.ubnt.com
[2017-02-18 13:50:10,278] <Ws> INFO websocket - Cloud websocket connection closed: 1001
[2017-02-18 13:50:12,293] <Ws> ERROR websocket - error: java.net.UnknownHostException: device.svc.ubnt.com
[2017-02-18 13:50:12,294] <Ws> INFO websocket - Cloud websocket connection closed: 1001
[2017-02-18 13:50:15,528] <Ws> ERROR websocket - error: java.net.UnknownHostException: device.svc.ubnt.com
[2017-02-18 13:50:15,531] <Ws> INFO websocket - Cloud websocket connection closed: 1001
[2017-02-18 13:50:22,276] <Ws> ERROR websocket - error: java.net.UnknownHostException: device.svc.ubnt.com
[2017-02-18 13:50:22,279] <Ws> INFO websocket - Cloud websocket connection closed: 1001
[2017-02-18 13:50:35,102] <Ws> INFO websocket - Cloud websocket connection closed: 1001
[2017-02-18 13:51:02,567] <Ws> ERROR websocket - error: java.net.UnknownHostException: device.svc.ubnt.com
[2017-02-18 13:51:02,568] <Ws> INFO websocket - Cloud websocket connection closed: 1001
[2017-02-18 13:51:52,080] <Ws> ERROR websocket - error: java.net.UnknownHostException: device.svc.ubnt.com
[2017-02-18 13:51:52,083] <Ws> INFO websocket - Cloud websocket connection closed: 1001
[2017-02-18 13:53:04,393] <Ws> ERROR websocket - error: java.net.UnknownHostException: device.svc.ubnt.com
[2017-02-18 13:53:04,396] <Ws> INFO websocket - Cloud websocket connection closed: 1001
[2017-02-18 13:53:06,401] <Ws> ERROR websocket - error: java.net.UnknownHostException: device.svc.ubnt.com
[2017-02-18 13:53:06,402] <Ws> INFO websocket - Cloud websocket connection closed: 1001
[2017-02-18 13:53:10,664] <Ws> ERROR websocket - error: java.net.UnknownHostException: device.svc.ubnt.com
[2017-02-18 13:53:10,667] <Ws> INFO websocket - Cloud websocket connection closed: 1001
[2017-02-18 13:53:19,013] <Ws> ERROR websocket - error: java.net.UnknownHostException: device.svc.ubnt.com
[2017-02-18 13:53:19,014] <Ws> INFO websocket - Cloud websocket connection closed: 1001
[2017-02-18 13:53:20,219] <Ws> ERROR websocket - error: java.net.UnknownHostException: device.svc.ubnt.com
[2017-02-18 13:53:20,223] <Ws> INFO websocket - Cloud websocket connection closed: 1001
[2017-02-18 13:53:22,228] <Ws> ERROR websocket - error: java.net.UnknownHostException: device.svc.ubnt.com
[2017-02-18 13:53:22,232] <Ws> INFO websocket - Cloud websocket connection closed: 1001
[2017-02-18 13:53:25,244] <Ws> ERROR websocket - error: java.net.UnknownHostException: device.svc.ubnt.com
[2017-02-18 13:53:25,247] <Ws> INFO websocket - Cloud websocket connection closed: 1001
[2017-02-18 13:53:30,917] <Ws> ERROR websocket - error: java.net.UnknownHostException: device.svc.ubnt.com
[2017-02-18 13:53:30,920] <Ws> INFO websocket - Cloud websocket connection closed: 1001
[2017-02-18 13:53:42,208] <Ws> ERROR websocket - error: java.net.UnknownHostException: device.svc.ubnt.com
[2017-02-18 13:53:42,212] <Ws> INFO websocket - Cloud websocket connection closed: 1001
[2017-02-18 13:54:00,119] <Ws> ERROR websocket - error: java.net.UnknownHostException: device.svc.ubnt.com
[2017-02-18 13:54:00,119] <Ws> INFO websocket - Cloud websocket connection closed: 1001
[2017-02-18 13:54:29,431] <Ws> ERROR websocket - error: java.net.UnknownHostException: device.svc.ubnt.com
[2017-02-18 13:54:29,432] <Ws> INFO websocket - Cloud websocket connection closed: 1001
[2017-02-18 13:55:32,478] <Ws> ERROR websocket - error: java.net.UnknownHostException: device.svc.ubnt.com
[2017-02-18 13:55:32,479] <Ws> INFO websocket - Cloud websocket connection closed: 1001
[2017-02-18 13:57:12,128] <Ws> ERROR websocket - error: java.net.UnknownHostException: device.svc.ubnt.com
[2017-02-18 13:57:12,132] <Ws> INFO websocket - Cloud websocket connection closed: 1001
net.schmizz.sshj.transport.TransportException: [HOST_KEY_NOT_VERIFIABLE] Не удалось проверить ssh-rsa ключ хоста с отпечатком I removed fingerprint для 192.168.1.20 на порту 22
[2017-02-18 14:00:24,147] <Ws> INFO websocket - Успешно подключено к облачному websocket
[2017-02-18 14:03:38,382] <inform_stat-11> ERROR dev - Ошибка в DeviceManager.processStat() java.util.ConcurrentModificationException
at java.util.LinkedHashMap$LinkedHashIterator.nextNode(LinkedHashMap.java:719)
at java.util.LinkedHashMap$LinkedKeyIterator.next(LinkedHashMap.java:742)
at com.ubnt.data.X.mergeFrom(Unknown Source)
at com.ubnt.service.super.return.o?0000(Unknown Source)
at com.ubnt.service.super.return.?00000(Unknown Source)
at com.ubnt.service.super.return.?00000(Unknown Source)
at com.ubnt.service.super.J.o00000(Unknown Source)
at com.ubnt.service.super.M$_o.run(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)

UI-Team

Guest

#10

15.02.2017 05:54:00

Правило 6001 — это правило, которое пропускает вашу подсеть LAN IP, и да, его нельзя удалить. На самом деле это даже не элемент конфигурации в базе данных, оно сгенерировано автоматически. Оно действительно там было, просто не отображалось из-за сбоя при применении настроек. Думаю, в этом случае восстановление резервной копии помогло прекратить эту проблему, но не из-за каких-то изменений, внесённых при восстановлении. Хотя, если говорить о действиях в этом контексте, я бы подумал, что обновление контроллера тоже могло бы это исправить. Спасибо за обратную связь, теперь у меня появилось чуть больше понимания, с чего можно исходить.

fiannuzz

Guest

#11

15.02.2017 00:58:00

Интересно, у меня всё подключено через сетевой фильтр. Возможно, это сработало так же, как вы делали вручную. Надеюсь, скоро исправят! Кто-нибудь успешно использовал роутер от стороннего производителя? Я использую CK для всего, так что, думаю, USG мне особо не нужен. Понимаю, что DPI и панель управления будут недоступны. Буду ли я что-то ещё терять? VPN между сайтами тоже не нужен.

fiannuzz Guest	#12 14.02.2017 07:13:00 Я почти уверен, что делал что-то вроде этого... Добавил правило, удалил правило, перезагружал всё полностью. Порт: 3389 Проброс IP: 0.0.0.0 Проброс порта: 3389

g2uUmBLM4cb7n7K

Guest

#13

11.02.2017 17:25:00

Хорошо, я исправил это. Как видно из лога, который я выложил выше, проблема началась 4 февраля. Контроллер был настроен на автоматическое резервное копирование каждые 7 дней, так что у меня была копия от 29 января. Я восстановил резерв и USG подключился без проблем. Я ломал голову, пытаясь понять, что изменилось между 29 января и 4 февраля. Не припоминаю, чтобы в этот период вносил какие-то изменения. Более того, я почти уверен, что не обновлял контроллер или прошивки для USG, Unifi Switch или точек доступа в это время. Я уже был на версии контроллера 5.4.9 (обновился на неё, когда она вышла 23-го числа). Позже я обновил контроллер до версии 5.4.11 и свич/APs до 3.7.39.6089, но только после того, как появилась проблема с конфигурацией.

Я сверил настройки от 29 января с настройками на 10 февраля, и единственные отличия были в правилах файервола LAN IN и LAN OUT. В настройках от 29 января было правило 6001 с названием «accounting defined network 192.168.1.0/24» и в LAN IN, и в LAN OUT, а в настройках от 10 февраля его не было. Я не припоминаю, чтобы удалял это правило (кстати, если навести курсор на него, появляется красный круг с перечёркнутым знаком — значит его нельзя удалить). Для меня это загадка, как оно могло исчезнуть.

UI-Team

Guest

#14

11.02.2017 06:59:00

Это никак не связано с конкретными переадресациями портов или даже с тем, настроены они у вас или нет, дело в том, что в EdgeOS есть узел конфигурации, который задаёт LAN-интерфейс для любых возможных порт форвардов (он присутствует вне зависимости от их наличия).

Обязательно должен быть интерфейс, который соответствует спецификации lan-interface. Этот список формируется из той же функции, что и часть настроек интерфейсов, и в итоге получается правильным. Не совсем понятно, как можно пропустить интерфейс(ы) там, но при этом корректно заполнить остальную конфигурацию. Недавно на этой неделе мне прислали резервную копию базы данных с затронутой системой. При беглом просмотре всё выглядит нормально, но я собираюсь восстановить её и проверить, воспроизводится ли ошибка, когда найдётся время.

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

g2uUmBLM4cb7n7K Guest	#15 10.02.2017 22:04:00 Я пытался добавить, а потом удалить правило проброса порта, после чего перезагрузил устройство, но это не помогло. Какое именно правило проброса порта ты добавлял и удалял, просто интересно?

fiannuzz

Guest

#16

09.02.2017 06:51:00

У меня были такие же проблемы с тем, что USG не проходил Provisioning, и в логах я тоже заметил ошибки с переадресацией портов. Перед тем как начать разбираться, я обновил CloudKey до последней версии. Не уверен, что именно помогло, но я поигрался с несколькими вещами и, кажется, сделал следующее в таком порядке:

- Сбросил USG и заново его подключил (но проблема осталась). Маршрутизация и все остальное работало нормально, хотя и отображалось, что provisioning не пройден.
- Создал правило переадресации портов на странице настроек роутера.
- Поменял имя роутера с MAC-адреса обратно на то, что было раньше.
- Также переименовал сайт на что-то другое.
- Удалил правило переадресации портов.
- Проблема осталась.
- Я уже собирался сдаться, но решил перезагрузить USG полностью — и после этого он прошёл provisioning!

Сейчас всё работает отлично, и роутер показывает статус "подключён".

Обновление: сегодня снова случилось то же самое. Я баловался в мобильном приложении (Android), добавил SSID и сделал пару изменений с ноутбука. Потом заметил, что provisioning снова не прошёл. Подключился по SSH к CloudKey и увидел те же ошибки с переадресацией портов. Создал правило перенаправления, удалил его и перезагрузил оборудование. Теперь статус снова "подключён".

g2uUmBLM4cb7n7K

Guest

#17

09.02.2017 04:13:00

Хорошо, я получил логи, и вот где всё пошло не так. Судя по всему, проблема связана с настройкой перенаправления портов.

[2017-02-04 21:40:35,448] <inform-12> INFO inform - от [f0:9f:c2:10:fd:29](Router, UGW3, 4.3.34.4943823): состояние=CONNECTED, ext/stun_ip=192.168.1.1, dev_ip=67.172.242.107, uptime=1672153
[2017-02-04 21:40:35,462] <inform-12> INFO dev - [cfgversion] устройство[f0:9f:c2:10:fd:29] provisioning: текущее[312f08257f0be268], ожидаемое[398cb31ec6b8bbb6]
[2017-02-04 21:40:35,801] <inform-12> INFO dev - [state] устройство[f0:9f:c2:10:fd:29] CONNECTED->PROVISIONING, срок действия состояния=1486269755
[2017-02-04 21:40:35,810] <inform-12> INFO inform - <<< [setparam] устройство[f0:9f:c2:10:fd:29]: [_type, cfgversion, system_cfg, blocked_sta, mgmt_cfg, server_time_in_utc]...
[2017-02-04 21:41:08,470] <inform-3> INFO inform - от [f0:9f:c2:10:fd:29](Router, UGW3, 4.3.34.4943823): состояние=PROVISIONING, ext/stun_ip=192.168.1.1, dev_ip=67.172.242.107, uptime=1672187
[2017-02-04 21:41:08,476] <inform-3> ERROR dev - [commit errors] устройство[f0:9f:c2:10:fd:29], { "DELETE" : { "failure" : "0" , "success" : "1"} , "SESSION_ID" : "37780dd580169ca0505c765cdb" , "SET" : { "error" : { "port-forward lan-interface " : "Неверное имя интерфейса\n\nПроверка значения не пройдена\n"} , "failure" : "1" , "success" : "1"}}
[2017-02-04 21:41:08,774] <inform-29> INFO inform - от [f0:9f:c2:10:fd:29](Router, UGW3, 4.3.34.4943823): состояние=PROVISIONING, ext/stun_ip=192.168.1.1, dev_ip=67.172.242.107, uptime=1672187
[2017-02-04 21:41:08,780] <inform-29> INFO dev - [cfgversion] устройство[f0:9f:c2:10:fd:29] provisioning: текущее[?], ожидаемое[398cb31ec6b8bbb6]
[2017-02-04 21:41:09,008] <inform-29> INFO inform - <<< [setparam] устройство[f0:9f:c2:10:fd:29]: [_type, cfgversion, system_cfg, blocked_sta, mgmt_cfg, server_time_in_utc]
[2017-02-04 21:41:09,650] <inform-14> INFO inform - от [80:2a:a8:96:e2:29](Family Room AP, U7PG2, 3.7.37.6065): состояние=CONNECTED, ext/stun_ip=192.168.1.188, dev_ip=192.168.1.188, uptime=945658...
[2017-02-04 21:41:41,717] <inform-25> INFO inform - от [f0:9f:c2:10:fd:29](Router, UGW3, 4.3.34.4943823): состояние=PROVISIONING, ext/stun_ip=192.168.1.1, dev_ip=67.172.242.107, uptime=1672220
[2017-02-04 21:41:41,721] <inform-25> ERROR dev - [commit errors] устройство[f0:9f:c2:10:fd:29], { "DELETE" : { "failure" : "0" , "success" : "1"} , "SESSION_ID" : "37780dd580169ca0505c765cdb" , "SET" : { "error" : { "port-forward lan-interface " : "Неверное имя интерфейса\n\nПроверка значения не пройдена\n"} , "failure" : "1" , "success" : "1"}}
[2017-02-04 21:41:42,021] <inform-27> INFO inform - от [f0:9f:c2:10:fd:29](Router, UGW3, 4.3.34.4943823): состояние=PROVISIONING, ext/stun_ip=192.168.1.1, dev_ip=67.172.242.107, uptime=1672220

Короче, это всё из-за того, что в настройках перенаправления порта указано неправильное имя интерфейса — от этого и все ошибки.

g2uUmBLM4cb7n7K

Guest

#18

09.02.2017 00:16:00

Судя по этой ветке, цикл подготовки вызван тем, что настройки из интерфейса неправильно передаются в файл system.config. Если найти повреждённую настройку, её можно изменить в интерфейсе, и тогда она правильно попадёт в файл system.config. Люди из другой ветки смогли найти проблему, проверив лог-файл контроллера. Как мне это сделать для контроллера на моём Cloud Key?

TDelac Guest	#19 09.02.2017 00:01:00 С нуля.

g2uUmBLM4cb7n7K Guest	#20 08.02.2017 23:50:00 Когда вы переносили всё на недавно созданный сайт, вы настраивали его заново с нуля или использовали какой-то упрощённый способ — например, экспорт/импорт сайта или восстановление из резервной копии?

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