Turris Omnia отказывается работать с разблокированным GPON-модемом MA5671A: eth2 никогда не поднимается на Turris OS 5.0.3
Пытаюсь заменить терминал провайдера в домашней стойке GPON-модемом прямо в роутере, чтобы оптоволокно заходило в одну коробку вместо двух. Модем определяется, и на этом хорошие новости заканчиваются.
- Turris Omnia на Turris OS 5.0.3, штатное ядро
- GPON-модем Huawei MA5671A с разблокированной прошивкой, выставлен в SGMII 1G
- пигтейл SC/APC от настенной розетки к модему
- eth2 - это порт SFP
Модуль определяется, но интерфейс так и не активируется:
# dmesg | grep sfp
SFP module encoding does not support 8b10b nor 64b66bПосле этого eth2 остаётся down, никакого carrier, счётчики пустые.
Что я уже пробовал:
- перепрошить модем обратно на штатную прошивку - при этом получаю ошибку чтения EEPROM вместо этого
- принудительно задать скорость через ethtool -s eth2 1000 autoneg off duplex full, после чего интерфейс держится на 10 Мбит полудуплекс
- переставить тот же модем в роутер MikroTik, где он действительно поднимается после ручной установки скорости порта
То есть сам модуль живой, и со стороны оптоволокна всё в порядке. Против чего именно в этом модеме возражает ядро, и какие GPON-модемы реально поднимаются на Omnia, а не отвергаются?
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 4
Это проблема на стороне хоста, а не мёртвый модуль. EEPROM в этих переделанных GPON-модемах декларирует кодировку, которую основной драйвер sfp не умеет сопоставить, поэтому phylink отказывается поднимать порт, а строка, которую вы привели, - это драйвер, говорящий именно об этом. Ваши собственные данные указывают туда же: тот же самый модем линкуется на MikroTik после ручной установки скорости порта, то есть с оптикой и стороной PON всё в порядке.
Единственное, что реально сдвинуло дело у меня, - это ядро, достаточно новое, чтобы нести особые правки под конкретные модули, что на Omnia означало тестовую ветку HBD с ядром 5.4. Предупреждаю сразу - это лишь частичная победа, и сильно зависит от того, какой у вас модем. На этом ядре:
Так что если хотите, чтобы Omnia заработала сейчас, а не когда-нибудь потом, я бы поставил в клетку именно DFP-34G-2C2. Проверьте на своей коробке, прежде чем на что-то полагаться - результаты здесь явно различаются между модемами и даже между версиями прошивки одного и того же модема.
Прежде чем начинать гадать, стоит уточнить две вещи. Во-первых, из какой ветки эта 5.0.3, и что показывает uname по ядру? Особые правки SFP под конкретные модули, нужные этим переделанным GPON-модемам, попали в код позже, так что поставляемое стабильное ядро и тестовое ведут себя совершенно по-разному с одним и тем же модулем.
Во-вторых, зарегистрирован ли серийный номер ONU на стороне провайдера? Модем, который так и не авторизован на OLT, будет выглядеть мёртвым, а многие провайдеры вообще отказываются регистрировать сторонний ONU.
И когда вы его вставляете, порт вообще переключается в inband/1000base-x, или лог останавливается прямо на этом сообщении о кодировке?
Стабильная ветка, штатное ядро для 5.0.3, ничего кастомного поверх. Сторона провайдера тут ни при чём - это то же самое волокно, и модем несёт зарегистрированный серийный номер.
Лог останавливается на строке про кодировку, порт никогда не переключается в inband/1000base-x. Что именно я получаю, зависит от прошивки. С разблокированной:
плюс модуль сообщает о transmit fault. Со штатной прошивкой дело даже до этого не доходит:
И, как уже сказал, принудительная установка скорости не даёт вообще ничего: после ethtool -s eth2 1000 autoneg off duplex full интерфейс всё равно держится на 10 Мбит полудуплекс.
Ещё один режим отказа, который стоит исключить на том же роутере, потому что выглядит похоже, но к кодировке отношения не имеет. HALNy HL-GSFP на Turris OS HBS 6.2.4 определялся, порт даже переключался в inband/1000base-x, а затем линк падал и eth2 оставался down.
Причина: этот модем сам по себе маленький компьютер. Ему нужна примерно минута на поднятие собственной прошивки, и только после этого он начинает отвечать клетке чем-то осмысленным. При холодной загрузке роутер заглядывает в клетку задолго до этого момента, определение не срабатывает, и коробка тихо откатывается на медную магнитку WAN. Увеличение задержки загрузки решило проблему:
Шестьдесят секунд вместо стандартных трёх, и кто-то ещё с тем же модемом это подтвердил. Ещё две вещи, которые помогли: отключить медный кабель WAN и перезагрузиться ещё раз, и зайти в сам модуль, чтобы посмотреть, в каком он состоянии - через последовательный порт на 38400 8N1 или по SSH на 192.168.77.154 порт 22666.