ODI DFP-34X-2C2 в Turris Omnia линкуется только на 1000base-x, ethtool не принимает speed 2500
Поменял ONU провайдера на стик ODI DFP-34X-2C2 GPON в своей Turris Omnia, чтобы оптика терминировалась прямо в роутере, а не в отдельной коробке на полке. Эта часть сработала: линия зарегистрирована, трафик ходит, никаких претензий. Проблема в скорости. Она никогда не превышает 1 Гбит/с, а 2.5G - вся причина, по которой я купил этот стик.
- Turris Omnia, TurrisOS 6.0.4
- стик ODI DFP-34X-2C2 GPON в слоте SFP, eth2
- медный WAN отключён, порт полностью принадлежит слоту
Что говорит ядро после загрузки, и что происходит при попытке задать скорость:
# dmesg | grep mvneta
eth2: switched to inband/1000base-x link mode
# ethtool -s eth2 speed 2500
Invalid argumentethtool eth2 при поднятом линке показывает модуль как 1000baseX/Full и ничего выше, и отказ выше - это ethtool, говорящий мне, что speed 2500 нельзя заявить.
Уже пробовал:
- зашёл по telnet в сам стик и задал скорость из его собственной оболочки; команда принимается, а потом всё равно возвращается на 1 Гбит/с
- перезагрузки с отключённым и подключённым медным WAN
- просмотрел dmesg на предмет чего-либо о том, что MAC предложили 2.5G - ничего нет
Это роутер ограничивает порт, или сам модуль? И есть ли что-то на стороне хоста, что заставит eth2 подняться на 2500base-x с этим стиком?
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 5
Потолок здесь - сам модуль, а не Omnia.
То, о чём хост договаривается - это то, что заявляет EEPROM модуля, потому что в момент опроса эта микросхема - единственное, на что может опереться слот. На этом стике она прошита на 1000 Мбит/с. Так что порт настраивается как inband/1000base-x, для phylink нет режима 2500base-x, который можно было бы предложить, и ethtool отказывает в speed 2500, потому что нечем это заявить. Никакой переключатель на стороне хоста этого не обойдёт: ethtool может запрашивать только те режимы, о существовании которых порту сказали. Оболочка внутри стика настраивает сторону PON модуля, а не то, что слот заявляет в сторону MAC - именно поэтому ваше изменение по telnet испаряется, и вы снова оказываетесь на 1 Гбит/с.
Остаются два реальных варианта: перепрошить модуль так, чтобы он заявлял 2.5G, либо заменить его на тот, что уже это умеет. Если пойдёте по пути перепрошивки, держите запасной на столе. Вы переписываете страницу идентификации, которой доверяет хост, и один неверный байт там даст вам модуль, который слот вообще перестанет распознавать. Также держите в голове, что это разные числа - то, что отдаёт сторона PON, и то, о чём согласуется линк SFP-MAC, так что разберитесь, что вы реально выигрываете, прежде чем тратить деньги на это.
Прежде чем винить стик, проверьте, какое device tree грузит коробка. Слот на Omnia - это не дополнительный интерфейс: он и металлическая половина WAN - это два фронтенда на один и тот же eth2, и только один из них в каждый момент реально подключён к MAC. Какой именно - решает dtb, который ядро загружает при старте. Так что посмотрите, на что указывает /boot/dtb: если это не armada-385-turris-omnia-sfp.dtb, вы смотрите на медную сторону, и цифры ничего не значат.
Также выложите полный dmesg | grep -i sfp, а не только строку mvneta. То, что ядро читает из модуля в момент опроса - вот что здесь интересно, и это обычно решает вопрос одной строкой.
dtb уже тот, что для SFP, я сделал симлинк на armada-385-turris-omnia-sfp.dtb, когда впервые поставил стик, иначе вообще ничего не поднималось. Слот владеет eth2, медный WAN отключён.
dmesg | grep -i sfp показывает, что модуль опознан, а дальше та же строка, что я уже приводил, eth2 switched to inband/1000base-x link mode. Про 2500 нигде ничего. ethtool eth2 сообщает 1000baseX/Full, пока линк поднят и передаёт трафик, а ethtool -s eth2 speed 2500 всё равно возвращает Invalid argument, то есть он вообще не заявляет 2500. Задание скорости по telnet внутри стика ведёт себя так же, как раньше: принимает команду, а затем откатывается на 1 Гбит/с.
Смежная история с той же платы, на случай если сюда попадёт кто-то со стиком, который вообще не поднимается, а не застрял на 1G. HALNy HL-GSFP в Omnia на Turris OS HBS 6.2.4: ядро его опознало, порт даже переключился на inband/1000base-x, а потом линк упал, и eth2 так и не поднялся.
Это не проблема EEPROM. Внутри этого стика живёт целая маленькая ОС, и ей нужна примерно минута наедине с собой, прежде чем она хоть в каком-то состоянии сможет отвечать хосту. При холодном старте роутер уже опросил слот и сдался задолго до этого момента, так что порт возвращается к медной магнитике. Здесь помогло увеличение задержки U-Boot:
По умолчанию 3 секунды; при 60 стик успевает полностью подняться к тому моменту, когда ядро добирается до опроса слота. Отключение медного WAN и повторная перезагрузка тоже помогли определению. И если когда-нибудь понадобится заглянуть внутрь стика, последовательный порт там 38400 8N1.
Согласен с диагнозом, с одной оговоркой для тех, кто придёт сюда с похожим симптомом. Не каждое "не умеет 2.5G" на этой плате - это модуль. Был снапшот OpenWrt, куда затащили обратным переносом общий код валидации phylink, и он прямо сломал слот на Omnia: ethtool по-прежнему заявлял 2500baseX/Full, но сообщал Link detected: no. Откат этого переноса вернул порт в прежнее состояние, ethtool читал Link detected: yes, 2500Mb/s full duplex, а более поздний pull request исправил перенос выше по течению.
Подсказка - в том, что ethtool перечисляет как supported и advertised. Если 2500baseX/Full там есть, а линк просто отказывается подниматься, смотрите на ядро и phylink после последнего обновления образа, а не на оптику. Если же, как здесь, порт вообще знает только про 1000baseX, потому что именно это модуль заявил о себе сам, никакое программное обеспечение хоста не наколдует режим. Это байт номинальной битовой скорости в EEPROM делает ровно то, что предписывает SFF-8472.