Каталог Поиск 0 Сравнить 0 Закладки 0 Корзина Войти
Каталог
105082, Москва, ул. Фридриха Энгельса, 75с21, БЦ Бауманский ИТКОЛ
Пн - Пт: с 09-00 до 18-00 Сб: с 10-00 до 18-00 Вс: выходной
Страницы: 1 2 След.
RSS
КАК: Восстановить ваш UniFi AP после «окирпичивания», UniFi Network
 
Отказ от ответственности: Открытие корпуса вашего AP, скорее всего, аннулирует гарантию, но если это сэкономит Ubiquiti несколько RMA, им вряд ли будет слишком обидно.  

Чтобы восстановить устройство, вам понадобится кабель Serial to TTL с уровнем сигнала 3.3 В. Я использовал USB-to-serial кабель вроде этого: www.adafruit.com/products/954  
Важно: НЕЛЬЗЯ использовать USB-to-RS-232 кабель! Этот тип имеет обратную полярность и выдает высокое напряжение (+/- 10В), что может вывести ваш AP из строя! И еще: ни в коем случае не подключайте провод питания!  

Эта процедура позволит восстановить любой AP с поврежденной прошивкой или конфигурацией. Она не поможет, если у устройства пропал загрузчик (что очень редко) или если есть электрические повреждения (ESD/удары молнии).  

Подключите ваш USB-to-TTL адаптер к ПК, а другой конец — к разъему внутри устройства. Это 4-контактный разъем с голыми золотыми пинами. Подключать нужно только 3 провода: GND, TX и RX. (НЕ используйте питание или Vcc от USB-to-serial адаптера!)  

Распиновка может отличаться в зависимости от модели, но GND всегда находится на одном из краёв. Его легко определить, так как он соединен с платой. Можно проверить мультиметром на целостность цепи между пином и платой (это та же серебристая часть корпуса разъема Ethernet) или внимательно посмотреть на плату и найти, к какому пину подключена медная фольга (лупа сильно помогает).  

Подключив GND, запускайте терминальную программу. Я пользовался minicom на Ubuntu, но для Windows подойдут hyperterm или teraterm (бесплатные). Обязательно установите параметры: 115200 бит/с, 8N1 (8 бит, 1 стоповый бит, нет контроля четности и потока).  

Проверьте работоспособность терминала, соединив короткой скрепкой провод TX и RX на конце кабеля. Если всё в порядке, вы увидите, как на экране повторяется то, что вы печатаете.  

Окей, теперь уберите скрепку и подключите RX к пину, который стоит рядом с GND в AP. Включите устройство. Если в течение секунды-двух на экране ничего не появилось, переставьте RX на следующий пин, перезапустите питание и смотрите опять. Если отображается мусор, значит неверная скорость передачи. Попробуйте другие, пока текст не станет читаемым. Для UniFi Outdoor это 115200.  

Разобравшись с RX, найдите пин для TX. Он всегда рядом с RX, максимум 2 варианта. Подключите TX к одному из них, перезагрузите AP и сразу начните быстро нажимать ESC. Если загрузочные сообщения прервались — значит, вы вошли в консоль! Если нет, попробуйте другой пин.  

Как только попадёте в консоль, введите команду «urescue», чтобы перевести устройство в режим приема TFTP. Настройте компьютер с IP 192.168.1.254 и подключите напрямую к AP (порт 1, если их два). Затем отправьте правильный файл firmware.bin (в двоичном режиме) на 192.168.1.20 через TFTP. Вы увидите прогресс в терминале. Ждите, пока AP полностью перезагрузится, прежде чем отключать питание! Обратите внимание, в этом режиме AP не отвечает на пинги.  

Запишите распиновку для будущих случаев, чтобы не тратить время (я забыл). Поделитесь здесь информацией для каждой модели!  

Мне показалось, что версия 2.2.5 — самая «безопасная» для отката. Учтите, что она НЕ стирает конфигурацию, так что после прошивки нажмите кнопку сброса или войдите в терминал и выполните команду syswrapper.sh restore-default. После этого у вас будет полностью «свежий» AP!  

Удачи! — Phil
 
О, у тебя будет ещё одна проблема с его настройкой. У меня есть детали, и я могу это исправить. Ты в Великобритании?
 
Порт Ethernet повреждён. Не могу использовать LAN.
 
Не уверен насчёт использования ymodem, вот что у меня есть; Загляни в мой пост здесь: https://community.ui.com/questions/0f4b7eff-d24b-4b91-8f03-ed8eb2571dc0 Я восстановил несколько точек доступа, используя этот процесс.
 
Привет! Как можно прошить новую прошивку через ymodem? Я использую команду LOADY, чтобы загрузить прошивку по адресу 0x81000000. И что дальше?
 
Если у кого-то есть информация по моему посту, пожалуйста, поделитесь. Спасибо!
 
Недавно я обновил прошивку на своем UAP-PRO, и после первоначальной перезагрузки он так и не включился. Раньше я пробовал метод soft TFTP, но на этот раз устройство просто не входит в режим восстановления через TFTP. Купил USB-TTL кабель, перепробовал все возможные варианты подключения проводов GND-TX-RX к четырем пинам на точке доступа, но без толку — в терминале ничего не появляется. Единственное, что горит — зелёный светодиод на корпусе AP. Если у кого есть идеи, пожалуйста, поделитесь. Спасибо.
 
Светодиод на боковой стороне точки доступа моргает один раз — больше ничего. Запустил процесс загрузки на 5 минут, как описано выше — слишком быстро, чтобы прервать. А что это за «другой» способ удалённого доступа?
 
Светодиод процессора всё ещё мигает или это тоже прекратилось? Есть ещё один способ удалённого доступа, который может «зависнуть» на какое-то время, прежде чем продолжит работу. Сколько ты ждал, чтобы увидеть, появится ли какой-то дополнительный вывод? Если только UBoot не повреждён каким-то образом, я не встречал случая, чтобы его нельзя было прервать на этапе загрузки uboot.
 
Конечно, сначала я попробовал все эти советы, прежде чем спрашивать. Процесс загрузки занимает около миллисекунды, при подаче питания светодиод кратко вспыхивает. Вот и всё! Полный отказ! Прерывание клавиатурой — нет, переключатель сброса — тоже нет.
 
Определённо нет, пришли мне это, если собираешься выбросить. Я всё ещё пытаюсь разобраться с первоначальным методом установки UBOOT, и иметь несколько нерабочих устройств для экспериментов — однозначный плюс. Однако попробуй сначала обычный способ восстановления через urescue, а если не получится — попробуй вот это: Unbrick. Если нужна подсказка, напиши мне, с радостью помогу.
 
Я бы согласился, что у вас есть связь, если вы можете через tftp загрузить прошивку, значит с Ethernet-оборудованием всё должно быть в порядке. Вы пробовали делать полный сброс к заводским настройкам? Возможно, у вас просто повреждённый конфиг, который в режиме восстановления не активен, так как в этот момент идёт процесс восстановления. Когда устройство загружается, оно применяет ваш конфиг, и именно тогда может проявиться проблема.
 
кирпич (отключение питания во время прошивки!) UAP-AC-M (Pico) Есть доступ по TTL — вот загрузка U-Boot unifi-v1.6.7.249-gb74e0282 (25 апр 2017 - 09:18:46)

DRAM:  
sri  
ath_ddr_initial_config(278): (инициализация ddr2)  
ath_sys_frequency: cpu 775 ddr 650 ahb 258  
Значения Tap = (0x8, 0x8, 0x8, 0x8)  
4 МБ  
Базовый адрес: 0x80000000, Верхний: 0x80400000, Зарезервированный logbuf: 0xa03fb000, log_magic: 0xa7ffbfff kseg: 0xa0000000  
Верхняя часть ОЗУ, доступная для U-Boot: 803fb000  
Резерв 247к под U-Boot по адресу: 803bc000  
Резерв 192к под malloc() по адресу: 8038c000  
Резерв 44 байта под Board Info по адресу: 8038bfd4  
Резерв 36 байта под Global Data по адресу: 8038bfb0  
Резерв 128к под параметры загрузки по адресу: 8036bfb0  
Указатель стека на: 8036bf98 Никак дальше не идет, ctrl-c или esc не прерывает? мусор для bin??
 
Что можно сделать — попробовать несколько записей перед сравнением. Иногда это действительно помогает. Сначала выполнить стирание, потом копирование, затем сравнение, снова копирование, сравнение и так далее. Нет смысла переходить к записи следующей части, если предыдущая не прошла успешно. Если не получится, то, к сожалению, флеш-микросхему придется менять, что само по себе не очень сложно при наличии хороших навыков пайки. Но проблема в том, чтобы подключиться к Uboot через JTAG, чтобы затем установить остальные разделы.
 
Всем привет, я попытался использовать скопированные разделы с моего работающего unifi-ap-lr-v2, вот лог:

U-Boot unifi-v1.6.15.278-g4ebbbcff (5 марта 2018 - 23:41:01)  
DRAM: 64 МБ  
Base:0x80000000, Top:0x84000000, Res logbuf:0xa3ffb000, log_magic:0x5b5a585a kseg: 0xa0000000  
Flash: 8 МБ  
Net: athr8032_phy_probe: unit=0, AR8032 Detected  
eth0: 78:8a:20:66:5b:87  
athr8032_phy_probe: unit=0, AR8032 Detected  
eth0  
Board: Copyright Ubiquiti Networks Inc. 2014  
Нажмите любую клавишу, чтобы остановить autoboot: 0  
Board: Ubiquiti Networks AR9342 board (e582-31.1122.0030)  

0. Name = u-boot, offset = 0, start_addr=9f000000, size=393216, start_sector=0, end_sector=51.  
1. Name = u-boot-env, offset = 60000, start_addr=9f060000, size=65536, start_sector=6, end_sector=62.  
2. Name = kernel, offset = 70000, start_addr=9f070000, size=7602176, start_sector=7, end_sector=1223.  
3. Name = cfg, offset = 7b0000, start_addr=9f7b0000, size=262144, start_sector=123, end_sector=1264.  
4. Name = EEPROM, offset = 7f0000, start_addr=9f7f0000, size=65536, start_sector=127, end_sector=127  

UBNT application initialized  
## Запуск образа по адресу 9f070000 ...  
Image Name: MIPS Ubiquiti Linux-2.6.32.33  
Created: 2018-03-17 18:32:47 UTC  
Image Type: MIPS Linux Kernel Image (lzma compressed)  
Data Size: 6578708 байт = 6.3 МБ  
Load Address: 80002000  
Entry Point: 80002000  
Проверка контрольной суммы по адресу 0x9f070040 ...  
Ошибка контрольной суммы  

ar7240> tftp 83000000 ubnt/mtdblock2  
Используется устройство eth0  
Получение по TFTP с сервера 192.168.1.254; наш IP: 192.168.1.20  
Имя файла 'ubnt/mtdblock2'.  
Адрес загрузки: 0x83000000  
Загрузка: ######################################################################################################################################################################################################################################################### done  
Передано байт: 7602176 (0x740000)  

ar7240> protect off all  
Снята защита с Flash Bank #1  

ar7240> erase 0x9f070000 +0x740000  
.................................................................................................................... done  
Стерто 116 секторов  

ar7240> cp.b 0x83000000 0x9f070000 0x740000  
Копирование в Flash... адрес записи: 9f070000 done  

ar7240> cmp.b 0x83000000 0x9f070000 0x740000  
Байт по адресу 0x831d0000 (0x8b) != байт по адресу 0x9f240000 (0xff)  
Всего совпало 1900544 байт  

ar7240> tftp 83000000 ubnt/mtdblock3  
Используется устройство eth0  
Получение по TFTP с сервера 192.168.1.254; наш IP: 192.168.1.20  
Имя файла 'ubnt/mtdblock3'.  
Адрес загрузки: 0x83000000  
Загрузка: #################################################### done  
Передано байт: 262144 (0x40000)  

ar7240> erase 0x9f170000 +0x40000  
.... done  
Стерто 4 сектора  

ar7240> cp.b 0x83000000 0x9f170000 0x40000  
Копирование в Flash... адрес записи: 9f170000 done  

ar7240> cmp.b 0x83000000 0x9f170000 0x40000  
Байт по адресу 0x83000000 (0x12) != байт по адресу 0x9f170000 (0x7b)  
Совпало 0 байт  

Сравнение не удалось как для mtdblock2, так и для mtdblock3. 🙁
 
IMO  
1. Попробуй восстановить прошивку через tftp или установить ddwrt/openwrt, а потом вернуть обратно на прошивку unifi (с помощью urescue или долгого зажатия кнопки) — если не сработает и по-прежнему будет ошибка bad crc.  
2. Выполни «mtdparts default» и снова попробуй tftp — если все равно ошибка bad crc.  
3. Скопируй или клонируй раздел и содержимое с похожего устройства, можно попросить другого пользователя сбросить имидж (у меня нет lrv2, я даже не знал, что есть ulr v2, пока ты не упомянул 😁) — если опять bad crc.  
4. Скорее всего, дело в железе — отправляй в ремонт (у нас в Индонезии есть любители и техники, которые делают такие работы). В других странах, возможно, это не стоит того, но у нас так делают.
 
Привет! Я знаю, что эта тема уже старая, но у меня есть забрикованный unifi-ap-lr-v2, который я пытаюсь оживить, но, к сожалению, безуспешно. Я обновлял устройство, когда произошло отключение электроэнергии. Это был unifi-lr-v2. Не подумав, я скачал прошивку с сервера unifi и успешно закинул её через tftp. После перезагрузки индикатор застыл на янтарном свете. Позже я понял, что прошивку я зашил от unifi-ap-lr, а не от версии v2. Поняв свою ошибку, я сразу же залил правильную прошивку, тоже успешно, но индикатор всё равно оставался янтарным. Я купил ttl-кабель, чтобы посмотреть, что происходит "под капотом", и обнаружил плохую CRC-ошибку данных. Я нашёл тему от @stevebird, но, к сожалению, никуда дальше не двинулся, так как для меня всё это с ttl новое. Я сделал бэкап работающих разделов unifi-lr-v2 через ssh, как советовал stevebird, но не получилось оживить устройство — думаю, из-за того, что адреса отличаются и я не смог понять, какие именно использовать. Прикладываю логи загрузки забрикованного unifi и надеюсь, что кто-то, особенно @stevebird, сможет помочь разобраться и оживить это устройство. Заранее спасибо всем, кто сможет поделиться информацией. Allan
 
Я в итоге пришёл к похожему выводу. Единственное, что меня всё ещё беспокоит — это то, что мне несколько раз удалось успешно закачать прошивку на устройство через tftp, так что в каком-то смысле связь всё же была возможна.
 
У меня такая же проблема, как у нескольких человек в этой теме — через TTL-подключение ничего не повреждено, но к точке доступа нельзя подключиться через Ethernet-интерфейс. Инструмент Unifi Discovery показывает точку доступа (UAP-LR) с IP по умолчанию 192.168.1.20, но достучаться до неё нельзя (никогда не отвечает на ping), даже в режиме восстановления через TFTP.

Я пытался понять, в чём дело. Провёл захват пакетов, и кажется, что устройство что-то передаёт (отправляет и широковещательные сообщения для обнаружения, и DHCP-запросы):  
dhcp, warning       default offering lease 10.1.17.105 for 44:D9:E7:2E:7D:AC without success

Но оно вообще ничего не получает в ответ.

Так что, как уже говорилось, похоже, что Ethernet-порт повреждён, хотя PHY при загрузке никаких ошибок не показывает.

Если кто-то смог точно определить проблему, буду благодарен, но поскольку это аппаратная неисправность, вряд ли стоит дальше этим заниматься.
 
Надеюсь, кто-то сможет помочь оживить старый UAP-LR. Он не отвечает на ping/ssh по адресу 192.168.1.20. Один раз удалось отправить на него новую прошивку через tftp, но поведение не изменилось. При загрузке устройства получаю следующий вывод в терминале, оно так и не проходит дальше «Booting...»:

U-Boot unifi-v1.5.2.206-g44e4c8bc (29 августа 2014 - 18:01:57)

DRAM: 64 МБ
Flash: 8 МБ
Обнаружен PCIe WLAN-модуль (попытка: 1).
Сети: eth0, eth1
Плата: Copyright Ubiquiti Networks Inc. 2014
Нажмите любую клавишу, чтобы остановить autoboot: 0
Плата: Ubiquiti Networks AR7241 board (e512-20.0101.002e)
Приложение UBNT инициализировано
## Загрузка образа по адресу 9f050000 ...
  Имя образа: MIPS Ubiquiti Linux-2.6.32.33
  Создан: 2017-09-16 5:35:32 UTC
  Тип образа: MIPS Linux Kernel Image (сжат LZMA)
  Размер данных: 921589 байт = 900 КБ
  Адрес загрузки: 80002000
  Точка входа: 80002000
  Проверка контрольной суммы по адресу 0x9f050040 ...OK
  Распаковка ядра ... OK

Запуск ядра...

Загрузка...

А вот вывод, когда я загружаю устройство в режиме tftp, удерживая кнопку сброса:

U-Boot unifi-v1.5.2.206-g44e4c8bc (29 августа 2014 - 18:01:57)

DRAM: 64 МБ
Flash: 8 МБ
Обнаружен PCIe WLAN-модуль (попытка: 1).
Сети: eth0, eth1
Плата: Copyright Ubiquiti Networks Inc. 2014
Нажмите любую клавишу, чтобы остановить autoboot: 0
Плата: Ubiquiti Networks AR7241 board (e512-20.0101.002e)
Приложение UBNT инициализировано
Кнопка сброса нажата: очистка раздела cfg!

Первый сектор 0x7b, последний 0x7e, размер сектора 0x10000
.... готово
Кнопка сброса нажата: очистка раздела u-boot-env!

Первый сектор 0x4, последний 0x4, размер сектора 0x10000
. готово
u-boot-env повреждён, заменяю на значение по умолчанию.

Первый сектор 0x4, последний 0x4, размер сектора 0x10000
. готово
Адрес записи: 9f040000
Установка IP по умолчанию 192.168.1.20
Запуск TFTP-сервера...
Используется eth0 (192.168.1.20), адрес: 0x81000000
Ожидание подключения: |

Буду признателен за любой совет.
Страницы: 1 2 След.
Читают тему (гостей: 1)