Палка FS GPON ONU в слоте SFP+ UDM-Pro: нет способа достучаться до её management IP, чтобы записать серийник

Asked 19 days ago Active 17 days ago Viewed 93 AI translation from English

Домашняя установка, пытаюсь избавиться от роутера провайдера на линии GPON Cosmote. Идея в том, чтобы завести оптику прямо в UDM-Pro и дать палке выполнять роль ONU, но провайдер принимает сессию только если предъявлен 12-символьный серийник и строка модели устройства старого CPE, так что мне нужно попасть внутрь модуля и записать и то, и другое.

Ubiquiti UDM-Pro, палка стоит в SFP+ порту 10
палка FS GPON ONU с MAC SFP, артикул 133619
патч-корд SC/APC - SC/APC от настенной розетки
старый CPE всё ещё на столе как образец для серийника и строки модели

Моя проблема более базовая, чем сам клонинг: я вообще не могу достучаться до модуля. Из шелла шлюза ничего не отвечает на его management-адрес.

ssh root@10.10.10.1
# then, from the gateway, with the stick in port 10
ssh ONTUSER@192.168.1.10

Вторая команда просто висит, пока не сдастся. Ни баннера, ни отказа в соединении, ничего.

Что уже сделал:

переустановил палку и поменял патч-корд, модуль запитывается, и его светодиод ведёт себя нормально
убедился, что на UDM-Pro ничего не занимает 192.168.1.0/24, моя LAN живёт в другой подсети
рассматривал вариант с выделенным management VLAN для этого слота, но это много сантехники ради одной записи

Есть ли способ адресоваться напрямую к слоту SFP из шелла UDM-Pro, чтобы залогиниться в палку и записать серийник и ID устройства, не поднимая для этого отдельный VLAN?

Show original (English) Also available in: English العربية Deutsch Español Français हिन्दी Bahasa Indonesia Italiano 日本語 한국어 Nederlands Polski Português Русский Türkçe Tiếng Việt 简体中文

sfpnode CN

Comments 4

Accepted answer

На пути у вас две отдельные вещи, и ни одна из них не сам модуль.

Первое - адресация. Слот SFP - это обычный интерфейс на UDM-Pro, пронумерованный как отображаемый номер порта минус один, так что порт 10 - это eth9. Дайте шлюзу адрес внутри подсети модуля и убедитесь, что ответы уходят именно с него:

ip addr add dev eth9 local 192.168.1.2/24
iptables -t nat -A POSTROUTING -o eth9 -d 192.168.1.0/24 -j SNAT --to 192.168.1.2

После этого 192.168.1.10 отвечает из шелла шлюза.

Второе - рукопожатие. Прошивка на этих палках достаточно старая, что её список алгоритмов обмена ключами останавливается на устаревших, так что нужно указать один явно:

ssh -oKexAlgorithms=+diffie-hellman-group1-sha1 ONTUSER@192.168.1.10

Как только зайдёте, серийник провайдера ставится через set_serial_number AVMGXXXXXXXX, а строка модели устройства клонируется через sfp_i2c -i7 -s. Перезагрузите палку и проверьте, что реально закрепилось:

fw_printenv | grep nSerial

Два предостережения. Ничего из этого не поддерживаемая конфигурация - вы вручную добавляете адрес и правило NAT на устройстве, так что относитесь к этому как к временной сантехнике на время сессии программирования и держите старый CPE, пока линия не аутентифицируется. Другая половина предупреждения про скорость: 2,5 Гбит - это то, на что эта платформа сама по себе не согласится, так что даже модуль, объявляющий 2.5G, в итоге договаривается либо на 1G, либо на 10G. Если вы вообще не хотите трогать шлюз, альтернатива - запрограммировать палку в другой коробке с маршрутизируемым портом SFP и потом переставить.

edgepilotID 19 days ago Show original (English) AI translation

Как сам шлюз называет этот слот? На этой коробке порты SFP - обычные интерфейсы, но именование не совпадает с номерами, напечатанными на передней панели, так что легко гонять пакеты через что-то, что вообще не этот слот - а из шелла это выглядит ровно так, как у вас: сессия висит, а на другом конце ничего.

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

coreadminDE 19 days ago Show original (English) AI translation

eth9 оказался именно тем, порт 10 минус один. Адрес плюс правило SNAT заставили 192.168.1.10 ответить с первой попытки, а опция устаревшего обмена ключами была другой половиной: без этого флага мой клиент сдавался во время рукопожатия, с ним я сразу получил приглашение ONTUSER.

Записал серийник через set_serial_number AVMGXXXXXXXX, клонировал строку модели через sfp_i2c -i7 -s, перезагрузил, и fw_printenv | grep nSerial возвращает установленное мной значение. Линия аутентифицировалась через несколько минут, старый CPE теперь отключён.

Одна вещь подтвердилась на собственном опыте: порт поднялся на 1G, ровно как предупреждали про 2,5G на этом слоте. Меня устраивает - таков профиль, что даёт провайдер здесь.

sfpnodeCN 18 days ago Show original (English) AI translation

Та же задача, другие детали, и именно серийник здесь становится неприятным. Я переносил идентичность Calix GigaPoint 801Gv2 на палку G-010S-A через ritool:

ritool set MfrID 3720
ritool set G984Serial 10010470
ritool set YPSerialNum 10010470

Серийник ONT - 372010010470, но модуль отчитывал его обратно как

read_sn_from_RI sn is: 3720101470

на один ноль короче. Причина в раскладке поля: серийник GPON - это 8 байт, первые четыре хранят vendor ID как ASCII-символы (3720 читается буквально как четыре буквы), а последние четыре - числовую часть, упакованную как hex. Десятичный хвост вроде 10010470 не помещается туда цифра в цифру, отсюда и потеря символа в эхе.

Так что прежде чем объявлять победу, проверьте, как ваш провайдер вообще регистрирует ONT - по серийнику или по SLID / регистрационному ID. Одна лишь запись серийника не всегда то, по чему они сверяют.

optictechES 17 days ago Show original (English) AI translation