Grosser Nachtrag
vom 12. Februar 2022
Ich habe mir in der Zwischenzeit bei Engitech einen zweiten SFP bestellt.
Heute pröbelte ich mehrere Stunden mit dem Router herum. Auch der neue SFP konnte keine Verbindung aufbauen.
Beim Durchstöbern des irgendwie völlig neu ausschauenden Foris GUIs blieb ich auf der Unterseite Snapshots hängen. Und was sieht mein Auge da: Am 15. Dezember gab es Update-Aktivitäten! Und zwar wurde um 16:26 Uhr ein „Automatic pre-update snapshot“ angefertigt, und um 16:34 Uhr ein „Automatic post-update snapshot (TurrisOS 5.3.3)“. Also genau dann, als meine Internetverbindung gekappt wurde.
Eine böse, böse Vorahnung beschlich mich — und tatsächlich, nachdem ich auf TurrisOS 3.11.23 downgegradet hatte („Rollback“, dann Reboot), lief der SFP wieder und ich konnte eine Internet-Verbindung herstellen.
Da ich ein Problem mit 5.3.3 vermutete, installierte ich daraufhin TOS 5.3.5 (per SSH auf den Router einloggen, dann updater.sh ausführen). Doch das Problem bestand bei dieser neueren Version weiter.
Doch jetzt hatte ich die nötigen Indizien, mich in den Turris-Foren nach anderen Opfern herumzuschauen, und tatsächlich: No SFP connectivity after upgrade from 3.x, und sogar ein Init7-Kunde.
Wenn ich die Bemerkung Turris OS 5.0+ no longer supports switching between SFP and metallic in runtime im Artikel zum Upgrade TOS 3.x auf 5.x richtig verstehe, wird beim Update der SFP deaktiviert und stattdessen die mit dem SFP „geteilte“ Ethernetschnittstelle reaktiviert. KEIN WUNDER GEHT DANN (BEI MIR, UND ANDEREN SFP-BENUTZERN) GAR NICHTS MEHR. Heise hat einen Leser schon vor zwei Jahren darauf hingewiesen, wie er das Problem beheben kann.
Ah, und auch das Rätsel ist gelöst: WAN interface that was originally labeled in the system as eth1 is now eth2.
Morgen Sonntag, während Stephanie am Brunchen ist, werde ich also den Router erneut lüpfen, den Device Tree Blob (dtb) umbiegen und so hoffentlich den SFP wieder hochkriegen. Bye bye FrickelBox, eh Fritz!Box.
Heute am 15. Dezember 2021 um 16:34 Uhr fiel bei uns das Internet aus: Copper7 über g.fast (meine vom 1. Oktober bis heute, dem 15. Dezember 2021, verwendeten Komponenten sind hier beschrieben).
Zuerst war ich der Meinung, dass es sich um einen Ausfall von Swisscom oder Copper7 handelt, doch als die Internetverbindung auch nach einer Stunde und einem Reboot des Turris Omnia immer noch getrennt war, machte ich mich ans Debugging.
Leider habe ich die Internetverbindung mit dem g.fast SFP im Turris Omnia bis jetzt nicht mehr zum Laufen gebracht. Wie im oben verlinkten Artikel beschrieben hatte ich die von Init7 gelieferte AVM Fritz!Box 7582 noch im Lager, und diese hat nun (leider) den Turris Omnia ersetzt. Ich hoffe nur temporär …
Derzeit sehe ich zwei Möglichkeiten:
- Swisscom hindert diesen spezifischen SFP seit heute an der Verbindungsaufnahme
- Der SFP hat nach 75 Tagen Dauerbetrieb (teilweise) den Geist aufgegeben
Um den Fehler einzugrenzen habe ich die letzten Stunden noch etwas rumgepröbelt, nachdem unsere Wohnung wieder ans Netz kam.
- Das Turris Omnia OS (TOS) ist 5.3.3
- Der Turris Omnia SFP-Port heisst eth2 (mysteriös, denn auf den Screenshots vom Oktober habe ich eth1 mit PPPoE konfiguriert)
- Ohne den SFP eingeschoben zu haben, gibt ethtool folgendes aus (MII = Media Independent Interface?):
# ethtool eth2 Settings for eth2: Supported ports: [ MII ] Supported link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Full Supported pause frame use: Symmetric Supports auto-negotiation: Yes Supported FEC modes: Not reported Advertised link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Full Advertised pause frame use: Symmetric Advertised auto-negotiation: Yes Advertised FEC modes: Not reported Speed: 10Mb/s Duplex: Half Port: MII PHYAD: 0 Transceiver: internal Auto-negotiation: on Supports Wake-on: d Wake-on: d Link detected: no
- Mit eingeschobenen SFP sieht die Ausgabe folgendermassen aus (TP = Twisted Pair?):
# ethtool eth2 Settings for eth2: Supported ports: [ TP ] Supported link modes: 1000baseX/Full Supported pause frame use: Symmetric Supports auto-negotiation: Yes Supported FEC modes: Not reported Advertised link modes: 1000baseX/Full Advertised pause frame use: Symmetric Advertised auto-negotiation: Yes Advertised FEC modes: Not reported Speed: 1000Mb/s Duplex: Full Port: Twisted Pair PHYAD: 0 Transceiver: internal Auto-negotiation: on MDI-X: Unknown Supports Wake-on: d Wake-on: d Link detected: no
- Informationen über das SFP-Modul gibt man folgendermassen aus (werden Informationen angezeigt, bedeutet das gleichzeitig auch, dass der SFP erkannt wurde und funktioniert):
# ethtool -m eth2 Identifier : 0x03 (SFP) Extended identifier : 0x04 (GBIC/SFP defined by 2-wire interface ID) Connector : 0x22 (RJ45) Transceiver codes : 0x00 0x00 0x00 0x01 0x00 0x00 0x00 0x00 0x00 Transceiver type : Ethernet: 1000BASE-SX Encoding : 0x01 (8B/10B) BR, Nominal : 1300MBd Rate identifier : 0x00 (unspecified) Length (SMF,km) : 0km Length (SMF) : 0m Length (50um) : 0m Length (62.5um) : 0m Length (Copper) : 255m Length (OM3) : 0m Laser wavelength : 0nm Vendor name : PROSCEND Vendor OUI : 00:00:00 Vendor PN : 190-T Vendor rev : V7.3 Option values : 0x08 0x00 Option : Retimer or CDR implemented BR margin, max : 0% BR margin, min : 0% Vendor SN : XXXXXXXXXXXXXXXX Date code : 210528__
- Wenn kein SFP eingesteckt ist:
# ethtool -m eth2 Cannot get Module EEPROM data: No such device or address
- Wenn es sich um keinen SFP Slot handelt:
# ethtool -m eth0 Cannot get module EEPROM information: Not supported
- Wird der SFP eingesteckt, findet man unter /var/log/messages folgende Mitteilung:
Dec 15 23:22:36 TURRIS-OMNIA kernel: [ 974.802636] sfp sfp: module PROSCEND 190-T rev V7.3 sn XXXXXXXXXXXXXXXX dc 28-05-21 Dec 15 23:22:36 TURRIS-OMNIA kernel: [ 974.811981] sfp sfp: unknown connector, encoding 8b10b, nominal bitrate 1.3Gbps +0% -0% Dec 15 23:22:36 TURRIS-OMNIA kernel: [ 974.820179] sfp sfp: 1000BaseSX+ 1000BaseLX- 1000BaseCX- 1000BaseT- 100BaseTLX- 1000BaseFX- BaseBX10- BasePX- Dec 15 23:22:36 TURRIS-OMNIA kernel: [ 974.830301] sfp sfp: 10GBaseSR- 10GBaseLR- 10GBaseLRM- 10GBaseER- Dec 15 23:22:36 TURRIS-OMNIA kernel: [ 974.836590] sfp sfp: Wavelength 0nm, fiber lengths: Dec 15 23:22:36 TURRIS-OMNIA kernel: [ 974.841657] sfp sfp: 9µm SM : unsupported Dec 15 23:22:36 TURRIS-OMNIA kernel: [ 974.846371] sfp sfp: 62.5µm MM OM1: unsupported/unspecified Dec 15 23:22:36 TURRIS-OMNIA kernel: [ 974.852135] sfp sfp: 50µm MM OM2: unsupported/unspecified Dec 15 23:22:36 TURRIS-OMNIA kernel: [ 974.857893] sfp sfp: 50µm MM OM3: unsupported/unspecified Dec 15 23:22:36 TURRIS-OMNIA kernel: [ 974.863657] sfp sfp: 50µm MM OM4: 2.540km Dec 15 23:22:36 TURRIS-OMNIA kernel: [ 974.868023] sfp sfp: Options: retimer Dec 15 23:22:36 TURRIS-OMNIA kernel: [ 974.871871] sfp sfp: Diagnostics:
- Mittels ip a sieht man noch weitere Infos — interessant ist NO-CARRIER (zu dem Zeitpunkt war das ADSL-Kabel nicht eingesteckt):
...4: eth2:
- Den SFP kann man über den i2c Bus abfragen. Bei mir ist der SFP unter /dev/i2c-5 ansprechbar. XXX ist die Seriennummer, YYY ist die MAC-Adresse:
# i2cdump 5 0x50 No size specified (using byte-data access) WARNING! This program can confuse your I2C bus, cause data loss and worse! I will probe file /dev/i2c-5, address 0x50, mode byte Continue? [Y/n] y 0 1 2 3 4 5 6 7 8 9 a b c d e f 0123456789abcdef 00: 03 04 22 00 00 00 01 00 00 00 00 01 0d 00 00 00 ??"...?....??... 10: 00 00 ff 00 50 52 4f 53 43 45 4e 44 20 20 20 20 ....PROSCEND 20: 20 20 20 20 00 00 00 00 31 39 30 2d 54 20 20 20 ....190-T 30: 20 20 20 20 20 20 20 20 56 37 2e 33 00 00 00 fe V7.3...? 40: 08 00 00 00 31 39 32 30 37 4b 35 38 39 32 31 35 ?... XXXXXXXXXXX 50: 30 30 34 38 32 31 30 35 32 38 00 00 00 00 00 92 XXXXXXXXXX.....? 60: 30 30 30 45 41 44 34 41 30 36 41 38 00 00 00 00 YYYYYYYYYYYY.... 70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................ 90: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................ a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................ b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................ c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................ d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................ e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................ f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................ - Entfernt man den SFP, erscheint folgender Eintrag in /var/log/messages:
Dec 15 23:21:22 TURRIS-OMNIA kernel: [ 901.123920] sfp sfp: module removed
2 Kommentare Kommentare
Hoi Mario
Bin gerade ueber deinen Post gestolpert. Ich wollte das SFP gerne in einem Netgate 2100 zum Laufen bekommen (siehe https://forum.netgate.com/topic/169552/netgate-2100-and-a-proscend-190-t-g-fast-sfp-modem/7). Laut Aussage von Init7 sollte das eigentlich theoretisch funktionieren (mit VLAN Tag 11). Leider bin ich bislang gar nicht so weit gekommen dass ich irgendwo in den Logs ein Lebenszeichen erkennen koennte.
Hast du da schon mehr herausgefunden?
BG,
Willi
Hi Mario,
Wollte gestern einen Omnia in Betrieb nehmen und dein Nachtrag hat mir wohl endlich die Antwort geliefert, warum die Kupferleitung nicht laufen wollte. Wenn das klappt, schick ich dir nen Blumenstraus!
Hab in den Docs nichts dergleichen gefunden, bis halt auf die Note beim Upgrade-Guide, nachdem ich deinen Post hier gelesen hab. Aber dass das sonst nirgend stand…
Liebe Grüsse,
Patrick