ALLNET ALL4781-VDSL2-SFP-Stick in einer Turris Omnia resynchronisiert alle 30 bis 120 Minuten
Ich habe meine VDSL2-Leitung endlich von der Box des Providers weggeholt und direkt auf der Turris Omnia terminiert, vor allem damit PPPoE auf dem Router läuft statt auf einem zweiten Gerät im Bridge-Modus. Der Aufbau war angenehm: Stick in den Käfig setzen, und das WAN-Interface wandert einfach auf das Modul, die Metallbuchse bleibt außen vor, der interne Link kommt von selbst hoch. Die grüne LED verfolgt den DSL-Sync, die orangene die Seite zum Router hin.
- Turris Omnia, PPPoE auf dem modemseitigen Interface konfiguriert
- ALLNET ALL4781-VDSL2-SFP Modem-Stick im SFP-Käfig
- VDSL2-Leitung, die volle 100 Mbit im Downstream trainiert
option ifname 'eth1.7', weil meine Leitung den VLAN-7-Tag will
Zehn Minuten Konfiguration plus ein Reboot, und es lief mit voller Leitungsrate. Das Problem ist, dass es nicht so bleibt. Irgendwo zwischen einer halben Stunde und zwei Stunden verliert das DSL den Sync und braucht zwei bis drei Minuten, um zurückzukommen:
LCP terminated by peer
Modem hangup
eth1: link is downWas ich schon gemacht habe:
- den Stick neu eingesetzt und den Router neu gestartet, das Intervall danach ist gleich
- das DSL-Patchkabel getauscht und den Stick an die erste Dose der Leitung gehängt
- das Kupfer-WAN-Kabel abgezogen, damit nichts um das Interface streiten kann
Nichts davon ändert das Muster. Liegt es am Stick, an meiner Leitung, oder daran, wie die Omnia den Käfig ansteuert? Betreibt hier jemand diesen Modem-Stick langfristig ohne Resyncs?
Comments 4
Das ist die bekannte schlechte Kombination: Firmware 3.4 auf einer Leitung, die tatsächlich 100 Mbit kann. Der Stick ist nicht an sich kaputt - eine andere Omnia, die ich kenne, betreibt dasselbe Modul schon lange auf einer VDSL2-Profil-17a-Leitung und hatte noch nie einen Resync, weshalb die Berichte zu diesem Ding so auseinandergehen, wie sie es tun. Welche Leitung in welche Gruppe fällt, lässt sich vorher nicht von einem Datenblatt ablesen.
Zwei Dinge, in dieser Reihenfolge.
Erstens beim Hersteller wegen der Firmware nachhaken. Sie haben eingeräumt, dass 3.4 sich falsch verhält, wenn die Leitung 100 Mbit erreichen kann, und der neuere Build kostet nichts, es gibt also keinen Grund, ihn nicht zu fahren.
Zweitens danach weiter die LEDs beobachten. Geht Grün zuerst aus, betrifft es DSL, Orange betrifft die Käfigseite. Fällt Grün auch auf dem neueren Build weiter aus, war die Firmware nicht die ganze Geschichte bei deiner Leitung.
Um beim Ergebnis ehrlich zu sein, da du sowieso danach fragen wirst: Ich kenne mindestens eine Leitung, bei der das Update nichts geändert hat und die Resyncs im gleichen Rhythmus von dreißig Minuten bis zwei Stunden weitergingen. Die Stabilität mit diesem Stick scheint ebenso von den Leitungseigenschaften abzuhängen wie vom Build, also die Firmware als das Billigste zum Ausprobieren behandeln, nicht als garantierte Lösung. Fällt es danach immer noch aus, ist der wenig glanzvolle Rückfall, wieder ein Modem davorzusetzen und die PPPoE-Sitzung auf dem Router über
eth1.7zu halten - man behält die vorhandene Konfiguration und hört auf, dem Sync hinterherzujagen.Welche Firmware läuft auf dem Stick? Es sind mehrere Builds im Umlauf, und sie verhalten sich auf schnellen Leitungen nicht gleich, das ist also als Erstes zu klären.
Zwei weitere Dinge, bevor der Router die Schuld bekommt. In dem Moment, in dem es abreißt, geht die grüne LED aus, oder bleibt sie an, während sich die orangene bewegt? Das sagt, ob der DSL-Sync verloren geht oder nur der Link Richtung Omnia. Und lässt sich aus dem Stick selbst in den Minuten vor einem Abriss etwas Brauchbares herausholen - erreichbare Rate, SNR-Marge, Fehlerzähler? Ein Sync, der seine Rate bis zur letzten Sekunde hält, liest sich ganz anders als einer, der vorher schon nach unten kriecht.
Firmware 3.4 auf dem Stick.
Ich saß neben der Box und habe drei Abrisse hintereinander erwischt: Grün geht zuerst aus, Orange bleibt die ganze Zeit an. Der Link Richtung Router bewegt sich also nie, es ist der DSL-Sync, der stirbt, und die PPPoE-Sitzung folgt ihm nach unten. Das macht
LCP terminated by peerauch eher zu einer Folge als zu einer Ursache, was ich vermutet, aber nicht bewiesen hatte.Bei den Zählern habe ich nichts zu bieten. Erreichbare Rate, Marge, Fehlerzahlen - der Stick zeigt davon nirgends etwas, das ich finden kann, und der Router zeigt mir die Sync-Rate und sonst nichts. Dieser Wert steht bis zur letzten Sekunde vor dem Verschwinden auf Leitungsrate, es kriecht also nichts vorher nach unten, es geht einfach weg. Das Profil hat sich auch nicht geändert, seit das Modem des Providers vor der Leitung saß.
Anderer Stick, derselbe Käfig, aber gut zu wissen, während du testest.
Ich hatte einen HALNy HL-GSFP GPON-Stick in einer Omnia: Der Kernel hat ihn anstandslos erkannt, der Port ist in inband/1000base-x gekippt, und dann blieb eth2 für immer down. Timing, keine Kompatibilität. Das Modul trägt ein eigenes kleines Betriebssystem und braucht fast eine Minute, bevor es auf irgendetwas antwortet, während der Käfig schon ein paar Sekunden nach dem Einschalten abgefragt wird. Die Abfrage findet niemanden zu Hause, der Router bleibt still beim metallischen WAN, und das SFP-Interface wacht nie auf.
fw_setenv bootdelay 60in u-boot hat das dauerhaft erledigt.Das erklärt keinen Resync mitten in einer Sitzung, ist also nicht deine Antwort. Aber wenn du nach einem Abriss mal neu bootest und dich auf Kupfer wiederfindest, ist das der Mechanismus, den du vor dir hast, kein totes Modul.