GPON光猫棒DFP-34X-2C2要过几十秒才在dmesg里出现,而且链路速率只有1G
我打算在终结我们WAN的Linux主机上用SFP GPON光猫棒替换运营商的ONT,结果这个棒子的行为完全不像一个普通收发模块。插进去之后腔位会安静半分钟以上,长到我有两次以为模块坏了,而等内核终于识别到它之后,链路又稳定在千兆速率,这就完全违背了折腾这一趟的初衷。
测试环境:
- Linux路由器主机,SFP腔位由内核SFP层驱动,主线内核
- ODI DFP-34X-2C2 GPON棒
- 另一个样品是华为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?还有ISP在PON侧给你的是什么速率,如果本来就是千兆套餐,那你拿到的这个链路速率就是对的,没什么需要修的。
很遗憾,这就是预期行为,而且不是你主机的问题。
GPON棒不是那种带EEPROM芯片的普通收发模块,它是塞进SFP外壳里的一台带自己SoC的小型Linux电脑,你主机通过I2C读到的EEPROM其实是这套系统模拟出来的。棒子自己的固件启动到足够能提供这些数据页之前,总线上什么都不会响应,这就是为什么普通模块立刻应答,而你要在那儿等上几十秒。你的模块识别行那一行前面的那段沉默,其实就是它在启动。
问题的另一半是,这些模拟出来的数据页里声明的内容经常本身就是错的。这类棒子主机侧的接口实际是2500BASE-X,但EEPROM却写着别的东西,SFP层照单全收,结果就定在了千兆模式。这两半问题内核都是靠针对具体模块的特殊处理(quirk)来解决的,而不是靠什么可配置项,OEM版的DFP-34X-2C2正是因为这个原因命中了其中一条quirk。
你手上的样品会不会命中这条quirk,取决于它报出来的厂商和型号字符串,而这些字符串在不同贴牌版本之间是不一样的,所以在你以为自己已经被覆盖之前,先比较一下你dmesg那一行打印的内容和quirk实际匹配的内容。
顺便说明一下为什么必须靠quirk这种办法:SFF-8472假设的是一个在正常I2C时序内就会响应的无源存储器件,标准里完全没有考虑过一个需要先启动半分钟才能说话的设备,所以严格遵循标准的主机完全有理由放弃这个模块,或者干脆相信它最终读到的那些模式位。
上面提到的贴牌问题才是实际的坑。匹配是靠厂商和型号字符串来做的,所以同一根物理棒子换个牌子卖,quirk就完全命中不上,链路又莫名其妙地退回千兆。另外也不要构建任何依赖"模块在启动后不久就出现"这个前提的东西,因为这场竞速在这里是赢不了的。
指望棒子厂商修好自家EEPROM内容这件事也过于乐观。这些问题被提出来的时候,连大型ISP从他们那里得到的回应都少得可怜。
同一类问题在消费级路由器上也出现,所以至少你不是一个人。Archer BE800、BE900和GE800的用户在10G SFP+ combo口插上棒子后,拿到的是1 Gbit/s,而不是他们付费的2.5 Gbit/s,TP-Link自己列出的、在这些端口上能用的棒子清单是ODI DFP-34X-2C2、华为MA5671A和诺基亚G-010SA——和大家最终折腾出来的那份短名单一模一样。
那边最初的建议是升级固件加重新插拔,重新插拔这一条也不是没道理,一个没有完全卡到位的模块确实会降速。后来的beta固件终于开放了端口配置,每个型号一个版本:
装上其中一个版本后,SFP端口模式就能通过telnet设置,先把接口停掉,比如
ip link set eth1 down之类。不过这终究只是个变通办法,不是真正的修复。一年之后同样的抱怨又冒出来了,而且不止是棒子的问题:有人在那个端口插的是JT-COM的JT-AOC-SFP-15 AOC,另一个人用的是Ampcom的无源10G SFP+ DAC,两个都卡在1 Gbit/s。
在有人建议把棒子挪到网卡上之前,值得先知道另一种失败模式。在x86上跑OpenWrt 19.07,配Intel X520和kmod-ixgbe,MA5671a会被直接当作不受支持的SFP拒绝。通过常规的模块配置文件设置allow_unsupported_sfp在那儿完全不起作用,这个参数必须在加载模块时给出:
而即便这样,驱动依然会拒绝它,因为棒子的EEPROM本来就没有描述出一个正常的收发模块,这个开关掩盖不了这一点。如果你最终真的挪到网卡上,先用一个普通的1000BASE-T、LX或SX模块验证一下这个端口本身没问题,不然你就是在同时调试网卡和棒子两个问题。
不过要小心别把这两者混为一谈。allow_unsupported_sfp是ixgbe内部的东西,决定的是这个驱动愿不愿意驱动某个光模块,这和这里要做的判断完全是两回事。等待时间长、模式不对,是通用SFP层读取模拟数据页、再把结果交给phylink导致的,针对具体模块的quirk就放在这一层。
在有正规SFP腔位的板子上,根本不存在ixgbe那个开关,那也不是解决办法;而在X520上,quirk列表同样救不了你。表面上是一样的症状,底层却是不同的层,把两者搞混就是有人白白重新编译驱动的原因。
顺便再划一条界限:让主机看到棒子,和让OLT接受它,是两个互不相关的问题,而且第二个问题可能糟糕得多。
有一个记录得很详细的案例:一根Xicom的DFP-34X-2C2,用setmac和OMCI查询把身份信息全套复制自一台中兴ZXHN F601——GPON序列号、PLOAM密码、LOID、硬件序列号、固件字符串,全都拷过去了。棒子测距一直到O5状态就停在那儿,没有分配ONU ID,也没有流量,因为到达O5只说明测距成功,而MIB上传还必须匹配OLT期望的那个ONT配置文件。那个帖子里没有人给出解决办法。
所以就算你在本地拿到了2500BASE-X,也别以为难点已经过去了。运营商如果把服务配置文件绑定到某一个特定的ONT型号上,那可能压根不存在一组能让第三方棒子被接受的复制字段。