ALLNET ALL4781-VDSL2-SFP插棒在Turris Omnia上每30到120分钟就重新同步一次
我终于把VDSL2线路从运营商的盒子上移走了，直接终结在Turris Omnia本身上，主要是想让PPPoE跑在路由器上，而不是跑在桥接模式下的第二台设备上。安装那部分很顺利：把插棒插进插槽，WAN接口就自动转移到了这个模块上，那个金属口彻底不再参与，内部链路自己就起来了。绿灯跟踪DSL同步状态，橙灯是朝向路由器那一侧的。
- Turris Omnia，在朝向猫的那个接口上配置了PPPoE
- SFP插槽里插着ALLNET ALL4781-VDSL2-SFP猫棒
- VDSL2线路能训练到满速100 Mbit下行
option ifname 'eth1.7'，因为我这条线要打VLAN 7的标签
花了十分钟配置加一次重启，线速就起来了。问题是它保持不住。半小时到两小时之间的某个时刻，DSL就会失步，然后需要两到三分钟才能恢复：
LCP terminated by peer
Modem hangup
eth1: link is down我已经做过的：
- 重新插拔了插棒并重启了路由器，之后的间隔时间一样
- 换了DSL跳线，把插棒挪到了线路的第一个插座上
- 拔掉了铜缆WAN口的线，确保没有东西在跟这个接口抢
这些都没能改变这个规律。这到底是插棒本身、我的线路，还是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
这正是那个已知的坏组合：固件3.4配上一条真能跑到100 Mbit的线路。这根棒子本身谈不上坏——我认识的另一台Omnia用同一个模块跑在一条VDSL2 profile 17a的线路上已经很长时间了，一次都没重新同步过，这也是为什么关于这东西的反馈会分成两派。哪条线会落到哪一派，事先光看参数表是看不出来的。
按这个顺序做两件事。
第一，去找厂商要固件。他们已经承认在线路能跑到100 Mbit的情况下3.4版本会出问题，新版本免费，没有理由不换上去。
第二，换完之后继续盯着指示灯。先灭的是绿灯就说明是DSL的问题，橙灯就说明是插槽这一侧的问题。如果换了新版本之后绿灯还在掉，那说明固件并不是你这条线全部的问题所在。
老实说结果，反正你也会问：我知道至少有一条线升级之后毫无变化，重新同步照样以同样的三十分钟到两小时的周期发生。这根棒子的稳定性看起来和线路本身的特性关系很大，不完全取决于固件版本，所以把固件升级当成成本最低的一次尝试，而不是保证有效的解药。如果升级之后依然掉线，不那么光彩但可行的退路是重新在前面放一个猫，PPPoE会话继续留在路由器上跑
eth1.7——这样你能保留已有的配置，也不用再追着同步问题跑。这根棒子上是什么固件版本？流通的版本不止一个，它们在快速线路上的表现也不一样，这是首先要确认清楚的。
再问两件事，然后再谈是不是路由器的问题。掉线那一刻，绿灯是灭了，还是一直亮着而橙灯在变化？这能告诉你到底是DSL同步丢了，还是只是朝Omnia那一侧的链路断了。另外，掉线前几分钟能不能从这根棒子本身拿到什么有用的信息——可达速率、信噪比余量、错误计数？一个直到断掉那一刻速率都保持满速的同步，和一个先慢慢往下爬的同步，读出来的含义完全不一样。
棒子上是固件3.4。
我坐在设备旁边连续抓到了三次掉线：绿灯先灭，橙灯全程一直亮着。所以朝路由器方向的链路根本没动过，是DSL同步先死掉，PPPoE会话跟着它一起掉了。这也说明
LCP terminated by peer是结果而不是原因，这正是我之前怀疑但没能证实的。计数方面我给不了你什么。可达速率、余量、错误计数——我在这根棒子上哪里都找不到这些信息，路由器只给我看同步速率，别的什么都没有。这个数字直到消失前的最后一刻都保持在线速，所以不存在先往下爬的过程，就是直接没了。而且从ISP的猫在线路前端的时候算起，这个profile也从没变过。
不同的棒子，同一个插槽，测试的时候值得知道这个。
我有一根HALNy HL-GSFP GPON棒子插在Omnia上：内核毫无怨言地识别了它，端口切换到了inband/1000base-x，然后eth2就一直卡在down状态，永远不会好。这是时序问题，不是兼容性问题。这个模块自带一个小型系统，需要将近一分钟才会对任何东西做出响应，而插槽在上电几秒钟之后就被探测了。探测的时候发现没人应答，路由器就默默留在金属WAN口上，SFP接口永远不会被唤醒。在u-boot里执行
fw_setenv bootdelay 60彻底解决了这个问题。这解释不了会话中途的重新同步问题，所以不是你要找的答案。但如果你哪次在掉线后重启，发现自己又回到了铜口上，那你面对的就是这个机制，而不是模块坏了。