ALLNET ALL4781-VDSL2-SFP-stick in een Turris Omnia resynct elke 30 tot 120 minuten
Ik heb mijn VDSL2-lijn eindelijk van de ISP-box gehaald en rechtstreeks op de Turris Omnia zelf afgesloten, vooral zodat PPPoE op de router draait in plaats van op een tweede apparaat in bridge-modus. Het opzetten was prettig: de stick in de cage plaatsen en de WAN-interface verhuist gewoon naar de module, waarbij de metalen aansluiting buiten beeld blijft, en de interne link komt vanzelf op. Het groene lampje volgt de DSL-sync, het oranje de kant richting de router.
- Turris Omnia, PPPoE geconfigureerd op de modem-kant-interface
- ALLNET ALL4781-VDSL2-SFP modemstick in de SFP-cage
- VDSL2-lijn die traint op de volle 100 Mbit down
option ifname 'eth1.7', omdat mijn lijn de VLAN 7-tag wil
Tien minuten configuratie plus een reboot en hij stond op met linesnelheid. Het probleem is dat hij niet blijft staan. Ergens tussen een half uur en twee uur desynct de DSL, en het duurt twee tot drie minuten voor hij terugkomt:
LCP terminated by peer
Modem hangup
eth1: link is downWat ik al gedaan heb:
- de stick opnieuw gezet en de router gereboot, het interval daarna is hetzelfde
- de DSL-patchkabel verwisseld en de stick naar de eerste aansluiting op de lijn verplaatst
- de koperen WAN-kabel losgekoppeld zodat er niets om de interface kan vechten
Niets daarvan verandert het patroon. Is dit de stick, mijn lijn, of de manier waarop de Omnia de cage aanstuurt? Draait iemand deze modemstick al lang zonder resyncs?
Comments 4
Dat is de bekende slechte combinatie: firmware 3.4 op een lijn die daadwerkelijk 100 Mbit haalt. De stick is op zich niet stuk - een andere Omnia die ik ken draait al lang dezelfde module op een VDSL2 profiel 17a-lijn en heeft nog nooit één keer geresynct, en dat is precies waarom de meldingen over dit ding zo uiteenlopen. Welke lijn in welke groep terechtkomt, is niet iets dat je vooraf van een datasheet kunt aflezen.
Twee dingen, in deze volgorde.
Ga eerst naar de fabrikant over de firmware. Ze hebben toegegeven dat 3.4 zich misdraagt op lijnen die 100 Mbit kunnen halen, en de nieuwere build kost niets, dus er is geen reden om hem niet te draaien.
Blijf daarna de lampjes in de gaten houden. Groen dat als eerste uitgaat betekent DSL, oranje betekent de cage-kant. Blijft groen op de nieuwere build nog steeds vallen, dan was de firmware niet het hele verhaal op jouw lijn.
Om eerlijk te zijn over de uitkomst, want je vraagt er toch naar: ik ken minstens één lijn waar de update niets veranderde en de resyncs op dezelfde dertig minuten tot twee uur doorgingen. Stabiliteit met deze stick lijkt net zo goed van de lijnkenmerken af te hangen als van de build, dus behandel de firmware als het goedkoopste om te proberen, niet als een gegarandeerde oplossing. Valt hij daarna nog steeds weg, dan is de onglamoureuze terugvaloptie om er weer een modem voor te zetten en de PPPoE-sessie op de router over
eth1.7te houden - je houdt de config die je al hebt en je stopt met de sync achterna te jagen.Welke firmware zit er op de stick? Er zijn meerdere builds in omloop en die gedragen zich niet hetzelfde op snelle lijnen, dus dat is het eerste om vast te pinnen.
Nog twee dingen voor je de router de schuld geeft. Gaat op het moment dat hij wegvalt het groene lampje uit, of blijft het branden terwijl het oranje beweegt? Dat vertelt je of de DSL-sync verloren gaat of alleen de link richting de Omnia. En kun je in de minuten voor een drop iets bruikbaars uit de stick zelf halen - attainable rate, SNR-marge, foutentellers? Een sync die zijn snelheid vasthoudt tot op de seconde dat hij sterft, leest heel anders dan een die eerst omlaag kruipt.
Firmware 3.4 op de stick.
Ik ben naast de box gaan zitten en heb drie drops op rij gevangen: groen gaat als eerste uit, oranje blijft de hele tijd aan. De link richting de router beweegt dus nooit, het is de DSL-sync die sterft en de PPPoE-sessie volgt daarin mee naar beneden. Dat maakt
LCP terminated by peerook een gevolg in plaats van een oorzaak, wat ik al vermoedde maar niet had bewezen.Over counters heb ik niets te melden. Attainable rate, marge, foutentellers - de stick geeft dat nergens vrij voor zover ik kan vinden, en de router toont mij de syncsnelheid en verder niets. Dat cijfer staat op linesnelheid tot op de seconde dat hij verdwijnt, dus er kruipt niets omlaag, het gaat gewoon meteen. Het profiel is ook niet veranderd sinds de ISP-modem voor de lijn stond.
Andere stick, zelfde cage, de moeite waard om te weten terwijl je aan het testen bent.
Ik had een HALNy HL-GSFP GPON-stick in een Omnia: de kernel pikte hem zonder klagen op, de poort schakelde naar inband/1000base-x, en daarna bleef eth2 voor eeuwig down staan. Timing, geen compatibiliteit. De module heeft een eigen kleine OS aan boord en wil het grootste deel van een minuut voor hij ergens op reageert, terwijl de cage al een handvol seconden na het inschakelen wordt bevraagd. De probe vindt niemand thuis, de router blijft stilletjes op de metalen WAN staan en de SFP-interface wordt nooit wakker.
fw_setenv bootdelay 60in u-boot loste het definitief op.Dat verklaart geen resync midden in een sessie, dus dat is niet jouw antwoord. Maar als je ooit na een drop reboot en jezelf op koper terugvindt, is dat het mechanisme waar je naar kijkt, geen dode module.