Posts Tagged ‘g.fast’

Sonntag, 13. Februar 2022

Tragödie: Turris OS 5.0 unterstützt meinen g.fast SFP nicht

Link zu diesem Artikel

Jetzt ist es klar: Trotz mehreren Stunden Investition habe ich es nicht geschafft, meinen Proscend T-190 g.fast SFP in meinem Turris Omnia mit Turris OS 5.3.5 zum Laufen zu bringen.

Wie der Router den SFP sieht:

[   13.657984] libphy: SFP I2C Bus: probed
[   14.013558] sfp sfp: module PROSCEND         190-T            rev V7.3 sn 19207J7B92080009 dc 31-08-20
[   14.022906] sfp sfp:   unknown connector, encoding 8b10b, nominal bitrate 1.3Gbps +0% -0%
[   14.031107] sfp sfp:   1000BaseSX+ 1000BaseLX- 1000BaseCX- 1000BaseT- 100BaseTLX- 1000BaseFX- BaseBX10- BasePX-
[   14.041249] sfp sfp:   10GBaseSR- 10GBaseLR- 10GBaseLRM- 10GBaseER-
[   14.047550] sfp sfp:   Wavelength 0nm, fiber lengths:
[   14.052617] sfp sfp:     9µm SM    : unsupported
[   14.057337] sfp sfp:  62.5µm MM OM1: unsupported/unspecified
[   14.063112] sfp sfp:    50µm MM OM2: unsupported/unspecified
[   14.068875] sfp sfp:    50µm MM OM3: unsupported/unspecified
[   14.074659] sfp sfp:    50µm MM OM4: 2.540km
[   14.079030] sfp sfp:   Options: retimer
[   14.082886] sfp sfp:   Diagnostics:

Vorbemerkung: Ja, das Folgende habe ich gemacht (resp. musste ich nicht machen, war schon so):

# ln -sf armada-385-turris-omnia-sfp.dtb /boot/dtb && reboot

Die Probleme begannen am 15. Dezember 2021, als der Router sich selbständig von TOS 3 auf 5 aktualisierte — und danach mit dem SFP keine Internet-Verbindung mehr möglich war. Ich habe darüber gebloggt.

Das Traurige: Unter TOS 3 funktioniert der SFP anstandslos.

Meine Vermutung ist es, dass das Problem mit inband/1000base-x zu tun hat:

...
[   13.913182] mvneta f1034000.ethernet eth2: switched to inband/1000base-x link mode
...

Bei TOS 3 lautete das noch:

...
[  340.701090] mvneta f1034000.ethernet eth1: Link is Up - 1Gbps/Full - flow control off
...

Ich habe nicht herausgefunden, ob und wie man das anpassen kann.

Ich habe einige Forenbeiträge gefunden, die einem helfen, das Problem nachzuvollziehen:

Vielleicht schafft es ja Turris OS 6.0 mit diesem Patch wieder, meinen SFPs zu unterstützen …

Tags: , , , ,
Labels: IT

1 Kommentar | neuen Kommentar verfassen

Donnerstag, 16. Dezember 2021

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

Link zu diesem Artikel

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

Tags: , , , , , , , , , , , , , , , , , , , ,
Labels: IT

2 Kommentare | neuen Kommentar verfassen

Sonntag, 10. Oktober 2021

Init7 Copper7 mit g.fast SFP

Link zu diesem Artikel

Am 15. Dezember 2021 um 16:34 starb unsere Internetverbindung, und bis jetzt konnte ich den g.fast SFP im Turris Omnia nicht mehr zum Laufen bringen. Momentan surfen wir über die AVM Fritz!Box 7582, welche ich für genau solche Fälle glücklicherweise im Archiv abgelegt hatte. Siehe den eigenständingen Blog-Artikel g.fast SFP in Turris Omnia debuggen (leider erfolglos)

Unser Umzug von der Stadt Bern in die Agglo (oder ist das hier schon „Land“?) hat sich gelohnt.

Der einzige Wermutstropfen aus IT-Sicht war, Fiber7 (1 Gbit/s symmetrisch; wenige Tage vor dem Umzug wurde der POP zudem fit gemacht für sagenhafte 25 GBit/s symmetrisch) hinter sich zu lassen und sich neu mit Copper7 g.fast (500 Mbit/s down, 100 Mbit/s up) begnügen zu müssen.

Bei der Umzugsmeldung an Init7 habe ich mir eine Fritz!Box 7582 mitbestellt, welche xDSL und g.fast kann.

Mein Plan war aber von vornherein, meinen Turris Omnia Router wenn irgendwie möglich auch hier weiterzubetreiben. Die Fritz!Box sollte nur für den Parallelbetrieb verwendet werden, und notfalls als Testgerät, falls ich mit dem Copper7-Support zu tun hätte und ich hätte sicherstellen müssen, dass ich mit einem offiziell unterstützen Gerät eine Verbindung aufbauen könnte.

Den Turris Omnia wollte ich aus folgenden Gründen weiterbetreiben: Nicht nur, weil der Router einfach besser geeignet für Nerds ist, sondern weil ich zu faul war, die voll funktionsfähige, jahrelang erprobte Konfiguration auf die Fritz!Box zu portieren.

Die einfachste Art, dies zu bewerkstelligen, den Fiber7-SFP (FlexOptix, ich habe darüber gebloggt) im Turris Omnia mit einem g.fast SFP zu ersetzen. Und dies gibt es auf dem Markt tatsächlich, es handelt sich aber um ein Nischenprodukt.

Hoffnung gab der Blog-Artikel Migrated to G.fast 500 Mbit DSL with Turris Omnia and SFP von Daniel Pocock, welcher genau das beschrieb, was ich vor hatte. Daniel gab mir freundlicherweise per Email noch Auskunft auf meine spezifischen Fragen. Top, und Danke!

Leider reagierte der von Daniel empfohlene Hersteller MVMTel auf mehrere meiner Anfragen (sowohl über das Web-Formular, als auch direkt per Email) nicht.

In der Schweiz machte ich zum Glück dann folgende zwei Anbieter von g.fast SFPs aus:

Ich bestellte die Ware bei Engitech, und am 1. Oktober 2021 war es so weit: Ich nahm den Fiber7-SFP aus dem Router raus, steckte den g.fast SFP rein, schloss das ADSL-Kabel an. Anschliessend musste ich das Protokoll des WAN-Interfaces (eth1, da SFP) noch von DHCP auf PPPoE umschalten und die von Copper7 per Email gesendeten Zugangsdaten eingeben (PAP/CHAP Username: INIT7.%benutzername%@downstream.ch, PAP/CHAP Password: siehe Datenblatt). Fertig. Nach wenigen Sekunden war der Router online.

Vorher:

Nachher:

Zwecks Troubleshooting noch dies: Der SFP verfügt über zwei LEDs, je auf einer Seite des SFPs. Wenn die Klemme des ADSL-Kabels nach unten zeigt, muss die rechte LED grün blinken („SGMII activity LED“), während die linke LED stetig orange (gelb?) leuchtet („MT5321 G.fast SFP link status“). Quelle

Sollte ich dereinst noch Zugriff auf ein Netzqualitäts- und Debug-Interface des Proscend SFPs finden, werde ich es hier posten. Hier ist die Fritz!Box meilenweit voraus:

Tags: , , , , , , , , , , ,
Labels: IT

2 Kommentare | neuen Kommentar verfassen