ALLNET ALL4781-VDSL2-SFP stick in a Turris Omnia resyncs every 30 to 120 minutes
I finally moved my VDSL2 line off the ISP box and terminated it on the Turris Omnia itself, mostly so that PPPoE runs on the router instead of on a second device in bridge mode. The setup part was pleasant: seat the stick in the cage and the WAN interface simply moves onto the module, leaving the metallic socket out of the picture, with the internal link coming up by itself. Green LED tracks DSL sync, the orange one the side facing the router.
- Turris Omnia, PPPoE configured on the modem-facing interface
- ALLNET ALL4781-VDSL2-SFP modem stick in the SFP cage
- VDSL2 line that trains at the full 100 Mbit down
option ifname 'eth1.7', because my line wants the VLAN 7 tag
Ten minutes of configuration plus a reboot and it was up at liine rate. The problem is that it does not stay up. Somewhere between half an hour and two hours the DSL desyncs, and it needs two to three minutes to come back:
LCP terminated by peer
Modem hangup
eth1: link is downWhat I have already done:
- reseated the stick and rebooted the router, the interval afterwards is the same
- swapped the DSL patch cable and moved the stick to the first socket on the line
- unplugged the copper WAN cable so that nothing can fight over the interface
None of it changes the pattern. Is this the stick, my line, or the way the Omnia drives the cage? Is anyone running this modem stick long term without resyncs?
Comments 4
That is the known bad combination: firmware 3.4 on a line that can actually do 100 Mbit. The stick is not broken as such - another Omnia I know of has been running the sme module on a VDSL2 profile 17a line for a long time and has never resynced once, which is why the reports on this thing split the way they do. Which line lands in which group is not something you can read off a datasheet beforehand.
Two things, in this order.
First, go to the vendor about the firmware. They have owned up to 3.4 misbehaving where the line can reach 100 Mbit, and the newer build costs nothing, so there is no reason not to run it.
Second, keep watching the LEDs afterwards. Green going out first means DSL, orange means the cage side. If green keeps dropping on the newer build, the firmware was not the whole story on your line.
Being honest about the outcome, since you will ask anyway: I know of at least one line where the update changed nothing and the resyncs continued at the same thirty minutes to two hours. Stability with this stick seems to depend on line characteristics as much as on the build, so treat the firmware as the cheapest thing to try rather than a guaranteed fix. If it still drops after that, the unglamorous fallback is to put a modem back in front and keep the PPPoE session on the router over
eth1.7- you keep the config you already have and you stop chasing the sync.Which firmware is on the stick? There is more than one build in circulation and they do not behave the same way on fast lines, so that is the first thing to pin down.
Two more things before you blame the router. At the moment it drops, does the green LED go out, or does it stay lit while the orange one moves? That tells you whether DSL sync is lost or only the link towards the Omnia. And can you get anything useful out of the stick itself in the minutes before a drop - attainable rate, SNR margin, error counters? A sync that holds its rate right up to the second it dies reads very differently from one that crawls downwards first.
Firmware 3.4 on the stick.
I sat next to the box and caught three drops in a row: green goes out first, orange stays on the whole time. So the link towards the router never moves, it is the DSL sync that dies and the PPPoE session follows it down. That also makes
LCP terminated by peera consequence rather than a cause, which is what I suspected but had not proven.On counters I have nothing to give you. Attainable rate, margin, error counts - the stick exposes none of it anywhere I can find, and the router shows me the sync rate and nothing else. That figure sits at line rate right up to the second it disappears, so nothing crawls downwards first, it simply goes. The profile has not changed since the ISP modem sat in front of the line either.
Different stick, same cage, worth knowing while you are testing.
I had a HALNy HL-GSFP GPON stick in an Omnia: the kernel picked it up without complaint, the port flipped into inband/1000base-x, and then eth2 sat there down forever. Timing, not compatibility. The module carries a small OS of its own and wants the better part of a minute before it will answer to anything, while the cage gets probed a handful of seconds after power-on. The probe finds nobody home, the router quietly stays on the metallic WAN and the SFP interface never wakes up.
fw_setenv bootdelay 60in u-boot settled it for good.That will not explain a resync in the middle of a session, so it is not your answer. But if you ever reboot after a drop and find yourself back on copper, that is the mechanism you are looking at, not a dead module.