GPON-стик DFP-34X-2C2 появляется в dmesg только через десятки секунд и затем линкуется на 1G
Заменяю операторский ONT на SFP GPON-стик на linux-боксе, который терминирует наш WAN, и стик ведёт себя совсем не как трансивер. Вставляешь его, и кейдж молчит полминуты или дольше, достаточно долго, чтобы я дважды решил, что модуль мёртв, а когда ядро наконец его замечает, линк устанавливается на гигабитной скорости, что сводит на нет весь смысл затеи.
Стенд:
- linux-роутер, кейдж SFP управляется слоем SFP ядра, mainline-ядро
- GPON-стик ODI DFP-34X-2C2
- стик Huawei MA5671a как второй образец
- обычный модуль 1G оптики, появляющийся мгновенно в том же кейдже, так что сам кейдж в порядке
$ dmesg | grep -E 'sfp|Link is'
[ 77.104] sfp sfp-p0: module ODI DFP-34X-2C2 rev sn dc
[ 79.610] eth1: Link is Up - 1Gbps/Full - flow control offЧто уже пробовал:
- переустановил стик и оставил его в покое на несколько минут, прежде чем трогать интерфейс, и задержка есть каждый раз, а не только при первой установке
- перезапустил интерфейс после обнаружения, что ничего не меняет в согласованном режиме
- MA5671a показывает такое же медленное появление, так что это не один плохой образец
Это просто так ведут себя GPON-стики на хосте Linux, или моя сторона делает что-то не так? Что реально происходит между установкой и обнаружением здесь?
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
简体中文
Comments 7
Прежде чем начнутся догадки, стоит уточнить две вещи. Во-первых, выложите полный необрезанный dmesg с момента установки, а не двухстрочный grep. Вы говорите, что кейдж работает через слой SFP ядра, и у меня нет причин сомневаться, но именно отфильтрованные вами строки показывают, сколько раз модуль опрашивался, что сдавалось между попытками и сколько времени занимала каждая попытка.
Во-вторых, что заявляет сам интерфейс о своих возможностях, когда стик наконец поднялся, и появляется ли 2500baseX где-либо в объявленных режимах? И какую скорость выдаёт вам провайдер на стороне PON, потому что если это гигабитный тариф, то линк, который вы получаете, правильный, и чинить нечего.
Ожидаемое поведение, к сожалению, и это не ваш хост.
GPON-стик - это не трансивер с чипом EEPROM внутри. Это маленький linux-компьютер на собственном SoC, втиснутый в корпус SFP, а EEPROM, который ваш хост читает по I2C, эмулирует эта система. На шине ничего не отвечает, пока собственная прошивка стика не загрузится достаточно, чтобы обслуживать эти страницы, поэтому вы сидите десятки секунд, пока обычный модуль отвечает мгновенно. Эта тишина перед строкой про ваш модуль - и есть загрузка.
Вторая половина вашей проблемы в том, что то, что заявляют эмулированные страницы, часто просто неверно. Интерфейс на стороне хоста у этих стиков - 2500BASE-X, а EEPROM говорит нечто другое, так что слой SFP принимает это за чистую монету и останавливается на гигабитном режиме. Обе половины решаются в ядре через специфичные для модуля обходы (quirks), а не через что-то настраиваемое, и OEM DFP-34X-2C2 попал под такой обход именно по этой причине.
Попадает ли ваш образец под него, зависит от строк вендора и партномера, которые он сообщает, а они различаются между ребрендами, так что сравните, что печатает ваша строка dmesg, с тем, на что срабатывает обход, прежде чем считать, что вы защищены.
Чтобы подчеркнуть, зачем вообще нужен подход через обходы: SFF-8472 предполагает пассивное устройство памяти, отвечающее в обычных таймингах I2C. Ничего в нём не предусматривает устройство, которому нужно полминуты загрузки, прежде чем оно сможет заговорить, так что хост, следующий стандарту, имеет полное право сдаться на модуле или довериться битам режима, которые он в итоге считает.
Момент про ребренды выше - практическая ловушка. Сопоставление идёт по строкам вендора и партномера, так что тот же физический стик, проданный под другим именем, полностью пропускает обход, и вы снова получаете гигабитный линк без очевидной причины. И не стройте ничего, что зависит от появления модуля вскоре после загрузки, потому что эту гонку здесь не выиграть.
Надеяться, что вендоры стиков исправят содержимое своего EEPROM, тоже оптимистично. Когда эти проблемы поднимались, даже крупные провайдеры получали от них очень мало обратной связи.
Та же категория проблемы всплывает на потребительских роутерах, так что вы не одиноки. Владельцы Archer BE800, BE900 и GE800 со стиком в комбо-порту 10G SFP+ получают 1 Гбит/с вместо 2,5, за которые платят, и собственный список TP-Link стиков, сообщённых как работающие в этих портах, - это ODI DFP-34X-2C2, Huawei MA5671A и Nokia G-010SA, тот же короткий список компонентов, к которому в итоге приходят все.
Первая линия совета там была прошивка плюс переустановка, и часть про переустановку не бессмыслица, модуль, не защёлкнувшийся до конца, действительно откатывается. Бета-сборки в итоге открыли настройку порта, по одной на модель:
С одной из них на коробке режим порта SFP становится настраиваемым через telnet, интерфейс сначала опускается,
ip link set eth1 downи так далее.Всё же это обходной путь, а не исправление. Год спустя те же жалобы продолжали поступать, и не только про стики: у одного человека был AOC JT-AOC-SFP-15 от JT-COM в этом порту, у другого пассивный DAC SFP+ 10G от Ampcom, и оба сидели на 1 Гбит/с.
Стоит знать про другой вид отказа, прежде чем кто-то предложит перенести стик на сетевую карту. На OpenWrt 19.07 на x86 с Intel X520 и kmod-ixgbe MA5671a просто отклоняется как неподдерживаемый SFP. Установка allow_unsupported_sfp через обычные файлы конфигурации модуля там вообще ничего не даёт, параметр нужно передавать при загрузке модуля:
И даже с этим драйвер всё равно отклоняет его, потому что EEPROM стика вообще не описывает обычный трансивер, и флаг не может это замаскировать. Если в итоге окажетесь на сетевой карте, проверьте порт обычным модулем 1000BASE-T, LX или SX сначала, иначе будете отлаживать карту и стик одновременно.
Только не запускайте эти два вместе. allow_unsupported_sfp живёт внутри ixgbe и решает, готов ли этот драйвер вообще управлять данной оптикой, что другое решение, чем то, что принимается здесь. Долгое ожидание и неправильный режим происходят от общего слоя SFP, читающего эмулированные страницы и передающего результат phylink, и именно там сидят специфичные для модуля обходы.
На плате с настоящим кейджем SFP флага ixgbe не существует, и он не решение, а на X520 список обходов вас тоже не спасёт. Симптом на поверхности тот же, слой под ним разный, и путать их - это как раз то, из-за чего люди зря пересобирают драйверы.
Ещё одна граница, которую стоит провести, раз уж вы этим занимаетесь: заставить хост увидеть стик и заставить OLT принять его - независимые задачи, и вторая может быть намного хуже.
Есть хорошо задокументированный случай, когда Xicom DFP-34X-2C2 был загружен идентичностью, скопированной с ZTE ZXHN F601 через setmac и запросы OMCI, GPON-серийник, пароль PLOAM, LOID, аппаратный серийник и строку прошивки - всё это. Стик доходит до состояния O5 и просто застревает там, без назначенного ONU ID и без трафика, потому что достижение O5 означает только успешный ranging, тогда как загрузка MIB всё ещё должна совпасть с профилем ONT, ожидаемым OLT. Никто в той теме так и не нашёл решения.
Так что когда у вас локально заработает 2500BASE-X, не считайте, что сложная часть позади. Там, где оператор привязывает сервисный профиль к конкретной модели ONT, может не существовать набора скопированных полей, который заставит принять сторонний стик.