GPON-Stick DFP-34X-2C2 taucht erst nach Dutzenden Sekunden in dmesg auf und linkt dann mit 1G
Ich ersetze den Provider-ONT durch einen SFP-GPON-Stick auf der Linux-Box, die unser WAN terminiert, und der Stick verhält sich überhaupt nicht wie ein Transceiver. Reinstecken, und der Käfig bleibt eine halbe Minute oder länger still, lang genug, dass ich zweimal dachte, das Modul sei tot, und wenn der Kernel es dann endlich bemerkt, pendelt sich der Link bei Gigabit-Geschwindigkeit ein, was den Sinn der Übung zunichtemacht.
Der Aufbau:
- Linux-Router-Box, SFP-Käfig von der Kernel-SFP-Schicht angesteuert, Mainline-Kernel
- ODI-DFP-34X-2C2-GPON-Stick
- ein Huawei-MA5671a-Stick als zweites Sample
- ein gewöhnliches 1G-Fasermodul, das im selben Käfig sofort erscheint, der Käfig selbst ist also in Ordnung
$ 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 offBisher versucht:
- den Stick neu gesteckt und mehrere Minuten in Ruhe gelassen, bevor das Interface angefasst wurde, und die Wartezeit ist jedes Mal da, nicht nur beim ersten Einstecken
- das Interface nach der Erkennung durchgetoggelt, was am ausgehandelten Modus nichts ändert
- der MA5671a zeigt dasselbe langsame Erscheinen, also kein einzelnes schlechtes Sample
Ist das einfach, wie sich GPON-Sticks an einem Linux-Host verhalten, oder mache ich auf meiner Seite etwas falsch? Was passiert hier tatsächlich zwischen Einstecken und Erkennung?
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
Bevor das Raten losgeht, zwei Dinge, die sich zu klären lohnen. Erstens: das ungekürzte dmesg ab dem Einstecken posten statt eines Zwei-Zeilen-Greps. Du sagst, der Käfig sitzt hinter der Kernel-SFP-Schicht, und ich habe keinen Grund, das zu bezweifeln, aber die Zeilen, die du rausgefiltert hast, sind genau die, die zeigen, wie oft das Modul abgefragt wurde, was dazwischen aufgegeben hat und wie lange jeder Versuch dauerte.
Zweitens: Was behauptet das Interface selbst, sobald der Stick endlich oben ist, und taucht 2500baseX irgendwo in den beworbenen Modi auf? Und welche Geschwindigkeit gibt dir der ISP auf der PON-Seite, denn wenn das ein Gigabit-Tarif ist, dann ist der Link, den du bekommst, der richtige, und es gibt nichts zu reparieren.
Leider erwartetes Verhalten, und es liegt nicht an deinem Host.
Ein GPON-Stick ist kein Transceiver mit einem EEPROM-Chip drin. Es ist ein kleiner Linux-Rechner auf einem eigenen SoC, in ein SFP-Gehäuse gequetscht, und das EEPROM, das dein Host über I2C liest, wird von diesem System emuliert. Auf dem Bus antwortet nichts, bis die eigene Firmware des Sticks weit genug gebootet ist, um diese Seiten zu bedienen, deshalb sitzt du dort Dutzende Sekunden, während ein normales Modul sofort antwortet. Diese Stille vor deiner Modul-Zeile ist der Boot.
Die zweite Hälfte deines Problems ist, dass das, was die emulierten Seiten angeben, häufig einfach falsch ist. Das hostseitige Interface bei diesen Sticks ist 2500BASE-X, und das EEPROM sagt etwas anderes, also nimmt die SFP-Schicht das für bare Münze und pendelt sich auf den Gigabit-Modus ein. Beide Hälften werden im Kernel mit Per-Modul-Quirks behandelt statt mit irgendetwas Konfigurierbarem, und der OEM-DFP-34X-2C2 hat genau aus diesem Grund einen dieser Quirks abbekommen.
Ob dein Sample davon erfasst wird, hängt von den Vendor- und Part-Strings ab, die es meldet, und die unterscheiden sich zwischen Rebadges, also vergleichen, was deine dmesg-Zeile ausgibt, mit dem, worauf der Quirk matcht, bevor man annimmt, abgedeckt zu sein.
Um zu unterstreichen, warum der Quirk-Ansatz überhaupt nötig ist: SFF-8472 geht von einem passiven Speicherbaustein aus, der innerhalb gewöhnlicher I2C-Timings antwortet. Nichts darin rechnet mit einem Gerät, das eine halbe Minute Boot braucht, bevor es sprechen kann, ein Host, der den Standard befolgt, hat also jedes Recht, das Modul aufzugeben oder den Mode-Bits zu vertrauen, die er irgendwann liest.
Der Rebadge-Punkt von oben ist die praktische Falle. Gematcht wird auf die Vendor- und Part-Strings, derselbe physische Stick unter anderem Namen verkauft verfehlt den Quirk also komplett, und man landet wieder bei einem Gigabit-Link ohne offensichtlichen Grund. Und nichts bauen, das davon abhängt, dass das Modul kurz nach dem Boot präsent ist, denn dieses Rennen ist hier nicht zu gewinnen.
Zu hoffen, dass die Stick-Hersteller ihre EEPROM-Inhalte fixen, ist auch optimistisch. Als diese Probleme angesprochen wurden, bekamen selbst große ISPs sehr wenig von ihnen zurück.
Dieselbe Problemklasse taucht bei Consumer-Routern auf, du bist also zumindest in Gesellschaft. Besitzer des Archer BE800, BE900 und GE800 mit einem Stick im 10G-SFP+-Combo-Port bekommen 1 Gbit/s statt der 2,5, für die sie bezahlen, und TP-Links eigene Liste von Sticks, die in diesen Ports gemeldet funktionieren, sind der ODI DFP-34X-2C2, der Huawei MA5671A und der Nokia G-010SA, dieselbe kurze Liste von Teilen, bei der jeder landet.
Der erste Rat dort war Firmware plus Neustecken, und der Neusteck-Teil ist kein Unsinn, ein Modul, das nicht ganz eingerastet ist, fällt tatsächlich zurück. Beta-Builds legten irgendwann eine Portkonfiguration offen, eine pro Modell:
Mit einer davon auf der Box wird der SFP-Port-Modus über Telnet einstellbar, Interface erst runtergefahren,
ip link set eth1 downund so weiter.Trotzdem nur ein Workaround und kein Fix, wohlgemerkt. Ein Jahr später kamen dieselben Beschwerden rein, und nicht nur über Sticks: Jemand hatte ein JT-AOC-SFP-15-AOC von JT-COM in diesem Port, jemand anders ein passives 10G-SFP+-DAC von Ampcom, und beide blieben bei 1 Gbit/s hängen.
Bevor jemand vorschlägt, den Stick auf eine NIC umzuziehen: Der andere Fehlermodus ist es wert, gekannt zu werden. Auf OpenWrt 19.07 auf x86 mit einer Intel X520 und kmod-ixgbe wird ein MA5671a einfach als unsupported SFP abgelehnt. allow_unsupported_sfp über die üblichen Modul-Konfigurationsdateien zu setzen bewirkt dort gar nichts, der Parameter muss beim Laden des Moduls übergeben werden:
Und selbst damit lehnt der Treiber ihn weiterhin ab, weil das EEPROM des Sticks von vornherein keinen normalen Transceiver beschreibt und das Flag das nicht überdecken kann. Wer doch auf einer NIC landet: Erst den Port mit einem gewöhnlichen 1000BASE-T-, LX- oder SX-Modul beweisen, sonst debuggt man Karte und Stick gleichzeitig.
Aufpassen, die beiden aber nicht zu vermischen. allow_unsupported_sfp lebt in ixgbe und entscheidet, ob dieser Treiber überhaupt bereit ist, eine gegebene Optik anzusteuern, eine andere Entscheidung als die, um die es hier geht. Die lange Wartezeit und der falsche Modus kommen daher, dass die generische SFP-Schicht die emulierten Seiten liest und das Ergebnis an phylink weiterreicht, und genau dort sitzen die Per-Modul-Quirks.
Auf einer Platine mit einem echten SFP-Käfig gibt es das ixgbe-Flag gar nicht, und es ist nicht der Fix, und auf einer X520 rettet einen die Quirk-Liste auch nicht. Gleiches Symptom an der Oberfläche, andere Schicht darunter, und diese beiden zu verwechseln ist, wie Leute am Ende umsonst Treiber neu bauen.
Noch eine Grenze, die sich zu ziehen lohnt, wo wir gerade dabei sind: Den Host dazu zu bringen, den Stick zu sehen, und die OLT dazu zu bringen, ihn zu akzeptieren, sind unabhängige Probleme, und das zweite kann weit schlimmer sein.
Es gibt einen gut dokumentierten Fall eines Xicom DFP-34X-2C2, dem die Identität eines ZTE ZXHN F601 aufgespielt wurde, mit setmac und OMCI-Abfragen, GPON-Seriennummer, PLOAM-Passwort, LOID, Hardware-Seriennummer und Firmware-String, alles davon. Der Stick rangiert bis zum O5-Status und bleibt dann einfach stehen, keine ONU-ID zugewiesen und kein Traffic, denn O5 zu erreichen heißt nur, dass das Ranging funktioniert hat, während der MIB-Upload immer noch zum ONT-Profil passen muss, das die OLT erwartet. Niemand in diesem Thread hat einen Fix zustande gebracht.
Wenn 2500BASE-X lokal also steht, nicht annehmen, der schwere Teil liege hinter einem. Bindet der Betreiber ein Serviceprofil an ein bestimmtes ONT-Modell, gibt es unter Umständen keine Kombination kopierter Felder, die einen Fremdstick akzeptiert bekommt.