Posts Tagged ‘Turris Omnia’

Montag, 30. Mai 2022

Turris Omnia auf einen anderen Branch wechseln

Je nachdem, auf welchen Branch man wechseln will, wählt man die entsprechende Zeile aus:

# switch-branch hbs # Stable, aka Snails
# switch-branch hbt # Testing, aka Turtle
# switch-branch hbl # Latest, aka Lions
# switch-branch crashlab

Tags: , , ,
Labels: IT

1 Kommentar | neuen Kommentar verfassen

Sonntag, 13. Februar 2022

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

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)

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

Sonntag, 10. Oktober 2021

Init7 Copper7 mit g.fast SFP

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

Sonntag, 29. August 2021

11.41TB

  • Uptime 207d 11h 59m 1s
  • RX 11.41TB
  • TX 4.55TB

Turris Omnia, powered by Fiber7. Wir werden die Glasfaser bald vermissen … popeliges #g.fast Ahoi!

Man beachte auch den Paket Counter Overflow … und auch, dass der Download um Faktor 2.5 höher ist als der Upload.

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

Keine Kommentare | neuen Kommentar verfassen

Sonntag, 10. Juni 2018

Init7 TV7: Turris Omnia, UniFi Switch, Multicast und IGMP Snooping

Seit der Ankündigung von Init7 verwende ich gelegentlich deren TV7-Angebot, welches ein ganz „normales“ Multicast IPTV ist.

Bei der Konfiguration des Services bei einer Bekannten, welche ich mit einem Ubiquiti EdgeRouter ER-X ausgestattet habe, musste ich feststellen, dass das Netzwerk wie vom ISP angedroht mit Multicast geflutet wird, wenn man einen TV-Sender schaut.

Das spürt man sehr gut, wenn man über den am ER-X angeschlossenen Ubiquiti UniFi AP-AC-LR surfen will oder bspw. eine SSH-Verbindung aufgebaut hat. Zwischen dem Druck einer Taste und dem erscheinen des Buchstabens in der Shell gibt es eine spürbare Verzögerung.

Damals war ich der Meinung, dass mein Turris Omnia hier zu Hause mit IPTV Multicast zu schlage kommt, weil ich solche Probleme initial nicht wahrnahm. Doch auch mein Netzwerk wird in Mitleidenschaft gezogen, und auch hier spüre ich es primär mittels Verbindungsproblemen mit dem UniFi Access Point. Da ich direkt nach dem Turris Omnia einen UniFi Switch US-8-60W angeschlossen habe und die Interface-Statistiken mit Cacti aufzeichne, kann ich das Problem einfach visualisieren — an Hand des Matches der Schweizer Nationalmannschaft gegen Japan am Freitag, 8. Juni 2018 ab 19 Uhr (wir schalteten uns ein paar Minuten später zu):

Man sieht auf den Graphen sehr gut, dass Multicast auf allen Interfaces des Switches einschlägt, egal, ob das Netzwerkgerät dahinter den Stream schaut oder nicht.

Was ich jetzt zudem auch noch realisiere: Meine Sonos PLAYBASAE, der SUB und die beiden Sonos PLAY:1 hatten Probleme mit der Audio-Wiedergabe von IPTV-Streams. Ich dachte, dass dies entweder an den Streams selber oder aber den Apps liegt, welche ich verwendet habe. Mir schwant nun aber, dass die PLAYBASE das Audio auf Grund des Multicast-Floodings eifach nicht schnell genug über den UniFi Access Point (d.h. per WLAN) zum SUB und den zwei PLAY:1 senden konnte.

Der Match lief bei uns über die App iPlayTV auf dem Apple TV 4 (mit Ethernet am UniFi-Switch angeschlossen) via HDMI auf unserem Panasonic Plasma in der Stube. Hierzu verwende ich udpxy, welches auf einem Linux-Server Intel NUC läuft, welcher ebenfalls am UniFi-Switch angeschlossen (dies nicht aus Spass; iPlayTV kommt mit der M3U8 respektive dem Multicast-Stream direkt von TV7 irgendwie nicht klar). D.h. udpxy empfängt Multicast, wandelt es in einen Unicast-Stream um und sendet diesen an den Apple TV.

Mitten im Spiel entschied ich mich, den Apple TV direkt an einen der vier freien Switch-Ports des Turris Omnia zu hängen (jetzt, als ich diese Zeilen schreibe, realisiere ich gerade, dass ich eigentlich den NUC dort hätte anhängen sollen, da er ja der Multicast-Empfänger war — und nicht den Apple TV). Das änderte an der Multicast-Flut nichts (wie auch, der Multicast-Empfänger war immer noch am Switch angehängt — ich Depp!).

Der Turris Omnia aber hat gemäss Kommandozeile IGMP-Snooping aktiviert:

$ cat /sys/devices/virtual/net/br-lan/bridge/multicast_snooping
1

Quellen: How can I enable IGMP Snooping in OpenWRT? sowie IPTV / UDP multicast

Schlussendlich nach viel Googlen dann die Erkenntnis: Ich musste IGMP Snooping noch auf meiner Ubiquiti-Netzwerkinfrastruktur aktivieren! Das macht man über den UniFi-Controller:

  1. Login auf die Web-Oberfläche des UniFi-Controllers
  2. Settings
  3. Networks
  4. Edit
  5. [x] Enable IGMP Snooping

Et voilà! Auf den Cacti-Graphen sind man in der Detail-Ansicht sehr schön, dass ich um spätestens 20:45 Uhr IGMP Snooping auf dem Switch aktiviert hatte:

Der Multicast-Stream mit locker 15 Mbit/s kommt immer noch über den Router auf dem Switch rein (Port 1, mit „TURRIS OMNIA“ bezeichnet), doch er wird nur noch an Switch-Port 3 weitergereicht, an welchem der NUC hängt, auf welchem udpxy läuft und den Multicast-Stream in Unicast umwandelt. Die anderen Ports werden mit Multicast sinnvollerweise nicht mehr bedient, und deshalb bricht die blaue Linie (Outbound-Traffic, d.h. in Richtung des angeschlossenen Netzwerkgerätes) fast gegen Null ein.

Was ich jetzt noch mache: Ich hänge den NUC auch noch direkt an einen freien Ethernet-Port des Turris Omnia. Dann gibt es eigentlich keinen Grund mehr, wieso Multicast-Traffic überhaupt bis zum UniFi-Switch gelangen sollte (ausser ich streame diesen bspw. auf meinem per Ethernet angebundenen iMac im Büro).

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

1 Kommentar | neuen Kommentar verfassen

Sonntag, 10. Juni 2018

Turris Omnia: Probleme mit pkgupdate debuggen

Mein Turris Omnia verwendet seit einiger Zeit das Kommandozeilentool pkgupdate, um sich zu aktualisieren (früher hatte diese Aufgabe offenbar ein Script namens updater.sh).

Gegen Ende dieser Woche wurde ich auf Grund eines nicht (mehr) existierenden Paketes regelmässig mit E-Mails eingedeckt, dass beim Update etwas fehlgeschlagen sein.

Beim Debuggen des Problems, welches ich in einem anderen Blog-Post beschreiben möchte, biss ich mir für einige Minute die Zähne an pkgupdater aus.

Gemäss Hilfe kann man mit dem Parameter -e die Verbosität des Tools einstellen:

$ pkgupdate --help
Usage: pkgupdate [OPTION]...
--help, -h			Prints this text.
--version, -V			Prints version of updater.
-R 			Use given path as a root directory. Consider also using --out-of-root option.
--batch				Run without user confirmation.
--state-log			Dump state to files in /etc/updater-state directory.
--ask-approval=	Require user's approval to proceed (abort if --approve with appropriate ID is not present, plan of action is put into the report-file if approval is needed)
--approve=			Approve actions with given ID (multiple allowed, from a corresponding report-file).
-s 		What level of messages to send to syslog.
-e 		What level of messages to send to stderr.
-S 		Under which name messages are send to syslog.
--task-log=		Append list of executed tasks into a log file.
--usign=			Path to usign tool used to verify packages signature. In default /usr/bin/usign.
--no-replan			Don't replan. Install everyting at once. Use this if updater you are running isn't from packages it installs.
--no-immediate-reboot		Don't reboot immediatelly. Just ignore immediate reboots. This is usable if you are not running on target machine.
--out-of-root			We are running updater out of root filesystem. This implies --no-replan and --no-immediate-reboot and is suggested to be used with -R option.

Doch was sind stderr Levels? Über eine Google-Suche stiess ich auch folgenden Kommentar zu einem völlig anderen Software-Produkt — sounds about right:

...
levels: {
  error: 3,
  warning: 4,
  notice: 5,
  info: 6,
  debug: 7,
},
...

Quelle: ‚debug‘ level is getting directed to stderr instead of stdout

debug war der Verbositäts-Level, welchen ich gesucht hatte. Versuchen wir es:

$ pkgupdate -e 7
DIE:Unknown log level 7
Aborted

Hmmm. Dann halt ausgeschrieben:

$ pkgupdate -e debug
DIE:Unknown log level debug
Aborted

Och Menno. Vielleicht dann alles in Grossbuchstaben?

$ pkgupdate -e DEBUG
DIE:Unknown log level DEBUG
Aborted

Himmelarsch! Zurück zu Google. Bei einem Gitlab-Checkin der Entwickler des Turris Omnia fand ich im Diff für das vorherige Script folgenden Hilfetext:

...
echo "-e (ERROR|WARNING|INFO|DBG|TRACE)	Message level printed on stderr. In default set to INFO."
...

Quelle: Store only single approved state

Somit lautet die korrekte Schreibweise:

# pkgupdate -e DBG

Und tatsächlich, damit klappte es.

Tags: , , , , , , ,
Labels: Linux

Keine Kommentare | neuen Kommentar verfassen

Mittwoch, 23. Mai 2018

Init7 TV7: Installation mit einem Turris Omnia-Router

Gestern liessen Fredy Künzler und seine Init7 die Überraschungsbombe platzen: Ab sofort gibt es TV7, das IPTV-Angebot des ISPs, für alle Fiber7-Kunden kostenlos zum spotgünstigen, symmetrischen 1 Gbit/s Internetabo hinzu:

Medienmitteilung vom 22. Mai 2018

Das bedeutet, dass ich nun über eine 1 GBit/s-Leitung feinste, unkomprimierte HD-Streams aller hierzulande gängigen und einiger eher exotischer Sender empfangen kann — derzeit 215 an der Zahl.

Wieso gerade jetzt? Aus meiner Sicht aus zwei Gründen: Erstens steht die Fussball-WM 2018 vor der Tür, wo man mit einem unkomprimierten Multicast-Stream die Überlegenheit über die Konkurrenz demonstrieren kann (fünf Sekunden vor dem Nachbarn das entscheidende Goal im Final sehen? Check.). Andererseits, weil Salt kürzlich mit seinem (geschwindigkeitstechnisch fragwürdigen) Fiber-Angebot Furore in den Medien gemacht hat, und dort auch IPTV draufpackt (inkl. schicker Integration in iOS).

Installation

Am Abend zog ich zu Hause die Bastelhandschuhe an und machte mich daran, die von TV7 ausgesendeten UDP Multicast-Streams über meinen Router ins interne Netzwerk zu transportieren.

Dank der vom ISP netterweise verfassten Anleitung für den Fiber7-Router meiner Wahl, den Turris Omnia, war das ein Klacks:

Anleitung Fiber7 TV7

Kurz zusammengefasst:

  1. In LuCI einloggen und unter System > Software das Softwarepaket igmpproxy installieren. Hierzu musste ich zuerst einmalig Update lists anklicken, und danach in das Suchfeld Filter den Namen des Pakets eingeben. Noch Find Package klicken und dann in der linken Spalte den Link Install anwählen.
  2. Per SSH auf die Kommandozeile des Routers einloggen und die Konfigurationsdatei unter /etc/config/igmpproxy anpassen (s. unten). Daraus wird dann /var/etc/igmpproxy.conf generiert
  3. In LuCI unter System > Startup igmpproxy auf enabled schalten und einmal start (resp. bei mehrmaligen Versuchen restart) drücken
  4. Per SSH auf der Kommandozeile des Routers mittels ps | grep -i igmp überprüfen, dass der Prozess läuft:
     6728 root       804 S    /usr/sbin/igmpproxy /var/etc/igmpproxy.conf

/etc/config/igmpproxy

config igmpproxy
	option quickleave 1

config phyint wan
	option network wan
	option direction upstream
	list altnet 0.0.0.0/0

config phyint lan
	option network lan
	option direction downstream

Init7 empfiehlt einen Reboot, welchen ich schlussendlich doch noch durchgeführt habe, aber nur, weil etwas mit dem Test-Stream (s. unten) nicht funktioniert hat. Ich kann mir vorstellen, dass der Router Multicast auch ohne Reboot hinkriegt, lasse mir aber gerne das Gegenteil bestätigen.

Test

Um möglichst viele potentiell störenden Parameter auszuschliessen, schloss ich mein MacBook 12″ mittels eines USB-C-auf-Ethernet-Adapters direkt an einen Ethernet-Port des Routers an. So schliesse ich aus, dass Switches zwischen dem Endgerät und dem Router Multicast vermüeseln (mein 8-Port UniFi- und mein 16-Port TP-LINK Gigabit-Switch funktionieren tadellos, ohne irgendwelche Konfiguration).

Anschliessend wollte ich den Empfang mit dem im FAQ-Artikel „Kann ich vorab testen, ob mein Router TV7 (Multicast) unterstützt?“ verlinkten Stream auf den Big Buck Bunny (Bedeutung) testen. Doch leider kriege ich diesen Stream bis heute nicht zu laufen — weshalb ich gestern zuerst auf ein Konfigurationsproblem tippte und deshalb den Router doch noch einem Kaltstart unterzog (ich bin mir fast sicher, dass das nicht nötig gewesen wäre).

Nachdem ich mir sicher war, dass igmpproxy sauber läuft, entschloss ich mich schlussendlich, einfach die im FAQ-Artikel „Kann ich TV7 auch auf anderen Geräten als Apple TV anschauen?“ erwähnte M3U-Datei herunterzuladen und in VLC 3.0.2 zu öffnen. Und siehe da: Wenige Sekunden später, nach nicht einmal 30 Minuten Installationsdauer, sah ich die Tagesschau gestochen scharf in höchster Auflösung auf dem Retina-Display meines MacBooks entgegenflimmern:

Tags: , , , , , , , , , , , ,
Labels: IT, Linux, Medien

2 Kommentare | neuen Kommentar verfassen

Samstag, 10. Februar 2018

Eine Eaton 3S550IEC USV an Turris Omnia anschliessen

Vor einiger Zeit habe ich mir für unsere Wohnung hier in Bern zwei USVs angeschafft.

Als IT-Supporter der alten Schule kommt mir beim Begriff USV spontan APC in den Sinn. Doch diese Teile sind teuer, weshalb ich mich im letzten Jahr je für eine Eaton 3S550IEC (550VA) sowie eine Eaton 3S700IEC (700VA) entschieden habe.

Im Büro hängt die USV an meiner Synology DS413, welche es mir erlaubt, die Vitaldaten mit Cacti aufzuzeichnen sowie das NAS herunterzufahren, wenn der Strom für längere Zeit ausfällt.

Im Wohnzimmer hatte ich ursprünglich keinen Server stehen, sondern nur einen Turris Omnia. Wie sollte ich also die Daten dieser USV aufzeichnen? Alsbald stellte sich heraus, dass das überhaupt keine Hexerei ist:

Man schliesst die USV per USB-Kabel (B auf A) an einen der USB-Port des Turris Omnia an, installiert über das LuCI-Interface die Pakete nut (Network UPS Tools) sowie nut-driver-usbhid-ups (beide in der Version 2.7.4-2) auf dem Turris Omnia.

Installiert man nut-driver-usbhid-ups nicht, sieht man in den Logs (ich glaube unter /tmp/log/messages, bin mir aber nicht mehr sicher) folgende Fehlermeldung:

2017-10-22T11:00:47+02:00 info upsd[30497]: listening on 0.0.0.0 port 3493
2017-10-22T11:00:47+02:00 warning upsd[30497]: /var/run is world readable
2017-10-22T11:00:47+02:00 err upsd[30497]: Can't connect to UPS [ups] (usbhid-ups-ups): No such file or directory
2017-10-22T11:00:47+02:00 info upsd[30498]: Startup successful

Sobald der Treiber installiert ist, lesen sich die Logs beruhigender:

2017-10-22T11:05:17+02:00 info usbhid-ups[558]: Startup successful
2017-10-22T11:05:17+02:00 info upsd[559]: listening on 0.0.0.0 port 3493
2017-10-22T11:05:17+02:00 warning upsd[559]: /var/run is world readable
2017-10-22T11:05:17+02:00 info upsd[559]: Connected to UPS [ups]: usbhid-ups-ups
2017-10-22T11:05:17+02:00 info upsd[560]: Startup successful

Der wichtigste Part kommt jetzt aber: Nun gilt es, von einem Linux-System die folgenden Konfigurationsdateien als Basis zu nehmen, zu kopieren und für den Turris Omnia zu adaptieren:

/etc/nut/hosts.conf
/etc/nut/nut.conf
/etc/nut/ups.conf
/etc/nut/upsd.conf
/etc/nut/upsd.users
/etc/nut/upsmon.conf
/etc/nut/upsset.conf

Angepasst habe ich schlussendlich nur folgende Dateien:

/etc/nut/upsd.users

[monuser]
		password = s1kr1t
		upsmon master

Mit diesem Benutzer und Passwort kann ich über das Netzwerk mit nut kommunizieren.

/etc/nut/upsd.conf

LISTEN 0.0.0.0

Dank dieser Konfigurationsdatei akzeptiert nut Anfragen von beliebigen Hosts im Netzwerk.

/etc/nut/ups.conf

pollinterval = 5

[ups]
	driver = usbhid-ups
	port = auto

Hier wähle ich den richtigen Treiber für die Kommunikation zwischen Turris Omnia und USV aus sowie lege fest, wie oft der Status der USV abgefragt wird.

/etc/nut/nut.conf

MODE=netserver

Sobald die Dateien installiert sind, startet man nut unter LuCI > System > Startup mit „Restart“ neu.

Der erste Ernstfall

Lustigerweise produzierte ich erst vorgestern Abend den ersten mir bewussten Ernstfall, als ich das Netzteil eines FLEXSON 3 INPUT HDMI SWITCH & AUDIO CONVERTER FOR SONOS PLAYBAR / PLAYBASE in die Steckerleiste einsteckte, den runden, geräteseitigen Ausgang aber noch nicht im Flexson-Gerät selber stecken hatte, sondern irgendwo auf unserem Fernsehmöbel herumliegen hatte – wo es wahrscheinlich mit irgendeinem einem Leiter Kontakt herstellte und so nicht nur das Netzteil grillte (mhmmm, dieser Geruch), sondern auch die Sicherung auslöste und das ganze Wohnzimmer ohne Strom war.

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

Keine Kommentare | neuen Kommentar verfassen

Dienstag, 21. November 2017

Turris Omnia: LuCI-Seite mit den Port-Weiterleitungen lädt im Schneckentempo

Vor einigen Wochen ist mir ein Bug in der LuCI Web-Oberfläche meines Turris Omnia aufgefallen: Die Seite zum Verwalten der Port-Weiterleitungen (ja, ich bin noch ein eingeschworener IPv4-Haushalt) lädt extrem langsam (Wartezeiten von über 2 Minuten). Will man dann auch noch einen bestehenden Eintrag bearbeiten, wartet man bis zu 16 Minuten (!), bis das Bearbeitungsformular geladen ist.

Mittlerweile habe ich einen Bug-Report im offiziellen Forum veröffentlicht, eine Lösung konnte mir aber noch nicht präsentiert werden. Immerhin haben sich bereits zwei Leidensgenossen gemeldet.

Aber aus einem Grund sind wir ja keine Klickibunti-Windows-Admins geworden und haben selbstverständlich auch den SSH-Zugang auf den Router freigeschaltet.

Die Anpassungen an den Firewall-Einstellungen finden sich in der Datei unter /etc/config/firewall. Am Besten kopiert man einfach einen bestehenden Eintrag und passt diesen nach den eigenen Wünschen an, zum Beispiel so:

...
config redirect
	option target 'DNAT'
	option src 'wan'
	option dest 'lan'
	option proto 'tcp udp'
	option src_dport '1234'
	option dest_ip '10.10.10.10'
	option dest_port '1234'
	option name 'sikrit hole'
...

Anschliessend speichert man die Datei und lädt die Firewall neu:

# /etc/init.d/firewall restart

Via: Add a firewall rule

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

1 Kommentar | neuen Kommentar verfassen