g.fast SFP in Turris Omnia debuggen (leider erfolglos)

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: mtu 1500 qdisc mq state DOWN group default qlen 532
link/ether XX:XX:XX:XX:XX:XX brd ff:ff:ff:ff:ff:ff

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