Posts Tagged ‘3.x’

Donnerstag, 16. Dezember 2021

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

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

1 Kommentar | neuen Kommentar verfassen

Donnerstag, 6. März 2014

rsync braucht unter Mac OS X ewig für „building file list…“

rsync ist das Tool meiner Wahl, um meine Backups auf mein Synology NAS im LAN sowie per WAN auf einen Linux-Server im Elternhaus zu spiegeln. Doch aufgepasst: Wer sich seit jeher daran stört, dass die Backup-Scripts bei hunderttausenden Dateien eine Ewigkeit bei „building file list…“ stehen bleiben, sei folgender Rat gegeben:

Man sollte unbedingt eine aktuelle Version von rsync – mindestens aber Version 3 – verwenden. Bis und mit Mac OS X 10.8 liefert Apple Version 2.6 mit, welche in dieser Hinsicht noch nicht optimiert wurde: Version 2 liest zuerst alle Dateien des Quellverzeichnis ein, während Version 3 nach den ersten 1000 Dateien (oder so) mit dem Backup beginnt und die verbleibenden Dateien anschliessend päckchenweise (nach Bedarf, basierend auf der Backup-Geschwindigkeit), einliest. Diese Massnahme verringert nebenbei auch gerade den RAM-Bedarf des Tools.

Version 3 ist auf meinem System über MacPorts installiert:

# port install rsync

Damit man auch wirklich sicher ist, dass in den eigenen Backup-Scripts Version 3 und nicht Version 2 verwendet wird, sollte man den rsync-Pfad in Scripts hardkodieren:

#RSYNC=$(which rsync)
RSYNC="/opt/local/bin/rsync/"

Um während der Ausführung eines Scripts zu prüfen, ob Version 3 des Tools verwendet wird, empfiehlt es sich, rsync das Argument --info=progress2 mitzugeben. In diesem Fall wird jede Datei, die kopiert wird, auf einer neuen Zeile ausgegeben. Neben dessen Grösse, dem Netzwerk-Durchsatz und der Transfergeschwindigkeit auf das Zielmedium steht ganz am Ende der Zeile einerseits xfr für die fortlaufende Nummer aller übertragender Dateien und Ordner sowie to-chk, die Zahl der bereits überprüften Dateien vom (provisorischen) Total aller Dateien. to-chk wird sich während der Laufzeit des Scripts sequentiell erhöhen.

$ rsync -av --info=progress2 . /mnt/backup/2014-03-06/
... 1,238,099 100%  146.38kB/s    0:00:08  (xfr#5, to-chk=169/396)
...

Tags: , , , , , ,
Labels: Linux

Keine Kommentare | neuen Kommentar verfassen