Turris Omnia 里的 ODI DFP-34X-2C2 只能以 1000base-x 连接，ethtool 不接受 speed 2500
我把运营商的 ONU 换成了 Turris Omnia 里的一个 ODI DFP-34X-2C2 GPON 棒子，让光纤直接终结在路由器里，而不是架子上另外一台设备里。这部分工作正常：线路已注册，流量能通，没有任何问题。问题在速率上。它从来没有超过 1Gbps，而 2.5G 正是我买这根棒子的全部原因。
- Turris Omnia，TurrisOS 6.0.4
- SFP 插槽里插着 ODI DFP-34X-2C2 GPON 棒子，对应 eth2
- 铜口 WAN 没有接，端口由这个插槽独占
开机后内核的输出，以及我尝试推速率时的反应：
# dmesg | grep mvneta
eth2: switched to inband/1000base-x link mode
# ethtool -s eth2 speed 2500
Invalid argument链路 up 时 ethtool eth2 显示模块是 1000baseX/Full，没有更高的选项，上面那个拒绝就是 ethtool 在告诉我 speed 2500 没法拿来协商。
已经尝试过：
- 用 telnet 登进棒子自己的 shell 设置速率；命令能被接受，但之后又变回 1Gbps
- 分别在接和不接铜口 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 里声明自己能做什么，因为在探测阶段，插槽唯一能依据的就是这颗芯片里的信息。这根棒子被编码成了 1000Mbps。所以端口被设置成 inband/1000base-x，phylink 根本没有 2500base-x 这个模式可以提供，ethtool 拒绝 speed 2500，是因为没有任何东西可以用来协商这个速率。主机这边没有任何开关能绕过这一点：ethtool 只能请求端口被告知存在的那些模式。棒子里的那个 shell 配置的是模块的 PON 一侧，而不是插槽向 MAC 那边宣告的能力，这正是为什么你在 telnet 里的改动会消失，最后又回到 1Gbps。
剩下的真正可行的选择只有两个：让人把模块重新编码，让它宣告支持 2.5G，或者换一个本来就支持的模块。如果走重新编码这条路，桌上一定要备一个备用件。你是在重写主机信任的身份信息页，写错一个字节，就会得到一个插槽根本不再识别的模块。另外要在脑子里把这两个速率分开：PON 侧实际交付的速率，和 SFP 到 MAC 这段链路协商出的速率，是两个完全不同的数字，先想清楚你到底能得到什么好处，再决定要不要为此花钱。
在怀疑光模块之前,先看看这台设备启动时用的是哪个 device tree。Omnia 上的 SFP 笼子并不是一个独立的接口:它和金属 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,不然根本起不来。SFP 笼子占用着 eth2,铜口 WAN 一直空着没接。
dmesg | grep -i sfp 显示模块被正确识别,然后就是我贴过的那一行,eth2 切换到 inband/1000base-x 链路模式,完全没提到 2500。ethtool eth2 显示链路 up、正常跑流量时是 1000baseX/Full,而 ethtool -s eth2 speed 2500 依然报 Invalid argument,也就是说它压根不会去协商 2500。在模块里通过 telnet 设置速率的表现也一样,先是接受了设置,然后又掉回 1Gbps。
同一款板子上的一个相邻案例，以防有人是遇到棒子完全起不来，而不是卡在 1G。在跑 Turris OS HBS 6.2.4 的 Omnia 上插了一个 HALNy HL-GSFP：内核识别出了它，端口甚至切换到了 inband/1000base-x，然后链路就掉了，eth2 再也没起来过。
那个不是 EEPROM 的问题。那根棒子里跑着一个完整的小操作系统，它需要大约一分钟的独立启动时间才能进入能响应主机的状态。冷启动时，路由器早在这之前就已经探测过插槽并放弃了，端口就退回到铜口那一侧的磁性元件上去了。延长 U-Boot 的延时解决了这个问题：
默认是 3 秒；设成 60 之后，等内核去探测插槽时，棒子已经启动完成了。拔掉铜口 WAN 再重启一次，对识别也有帮助。另外如果你以后需要看棒子内部情况，它的串口是 38400 8N1。
同意这个诊断，不过给以后遇到类似症状的人提个醒。不是所有在这块板子上「跑不到 2.5G」的情况都是模块的问题。曾经有一个 OpenWrt 快照版本回合并了通用的 phylink validate 代码，直接把 Omnia 的插槽搞坏了：ethtool 依然会宣告支持 2500baseX/Full，但报告 Link detected: no。回退那次回合并之后，端口恢复了原样，ethtool 显示 Link detected: yes，2500Mb/s 全双工，后来上游也有一个 pull request 把这个回合并本身修好了。
判断的关键在于 ethtool 列出的 supported 和 advertised 里有什么。如果 2500baseX/Full 已经在列表里，但链路就是起不来，那应该去查上次升级镜像之后的内核和 phylink，而不是去查光模块。如果像这个案例一样，端口从头到尾就只知道 1000baseX，因为那是模块自己声明的能力，那不管什么主机侧的软件都变不出这个模式来。这就是 EEPROM 里那个标称比特率字节，完全按照 SFF-8472 的规定在起作用。