Posts Tagged ‘Turris’

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, 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

Sonntag, 15. Januar 2017

snmpd-Konfiguration unter OpenWrt (Turris Omnia) anpassen

Auf Grund des in meinem Forum-Artikels geschilderten Problems der nicht zugänglichen Web-Interfaces meines Turris Omnias (das Problem trat kürzlich wieder auf), entschied ich mich, den von /tmp verwendeten Speicherplatz zu überwachen und mich beim Unterschreiten eines bestimmten Wertes zu alarmieren.

Was gibt es besseres, als den bereits laufenden SNMP-Daemon für diese Information anzuzapfen? Doch leider realisierte ich erst nach ein, zwei Stunden pröbeln, dass snmpd Dateisysteme vom Typ tmpfs nicht in den SNMP-Baum aufnimmt (weitere Diskussion hier sowie hier).

Doch vorerst setzte ich mich mit der snmpd-Konfiguration unter /etc/snmp/snmpd.conf auseinander. Beim Turris Omnia handelt es sich hierbei um einen Symlink auf die Datei /var/run/snmpd.conf. Doch bearbeitet man diese Datei und startet SNMP über die LuCI-Web-Oberfläche neu, werden die Anpassungen wie von Geisterhand mit den ursprünglichen Standardwerten überschrieben.

Nach ca. einer halben Stunde pröbeln und Googlen dann die Erkenntnis: Die Konfigurationsdatei ist — wie für OpenWrt typisch — unter /etc/config/snmpd abgelegt. Und zwar in einem OpenWrt-Format.

Darauf gestossen bin ich, als ich folgenden Befehl ausgeführt habe, welcher mir den Standort aller Dateien dieses Pakets zeigt:

# opkg files snmpd
Package snmpd (5.4.4-3) is installed on root and has the following files:
/etc/init.d/snmpd
/etc/config/snmpd
/usr/sbin/snmpd
/etc/snmp/snmpd.conf

Nimmt man die Anpassungen an sysLocation und sysContact hier vor, bleiben sie beim Neustarten des Daemons wie auch des Routers erhalten. Doch leider kann man in der unnötig komplexen Syntax nicht einfach neue Direktiven einbauen — diese müssen dem Start-Script unter /etc/init.d/snmpd explizit bekannt sein. So ist es zwar möglich, Einträge in der Form

disk /tmp 10%

einzubauen, indem man die Datei unter /etc/config/snmpd mit folgenden Zeilen ergänzt:

...
config disk
	option partition /tmp
	option size '10%'

Doch den Parameter includeAllDisks kennt das Script nicht. Halleluja für die aus meiner Sicht unnötige Komplexität, die dieser zusätzliche Konfigurationslayer dem Benutzer aufzwingt …

Im Internet habe ich nach etwas Googlen einen Patch gefunden, mit welchem der includeAllDisks-Parameter nachgerüstet werden kann. Mein Code von /etc/init.d/snmpd schaut deshalb nun so aus:

...
snmpd_disk_add() {
        local cfg="$1"
        local disk='disk'

        config_get partition "$cfg" partition
        [ -n "$partition" ] || return 0
        config_get size "$cfg" size
        [ -n "$size" ] || return 0

        if [ "$partition" == "includeAllDisks" ]; then
            echo "includeAllDisks $size" >> $CONFIGFILE
        else
            echo "disk $partition $size" >> $CONFIGFILE
        fi
        #echo "$disk $partition $size" >> $CONFIGFILE
}
...

Nun ist es mir möglich, includeAllDisks in der Konfiguration zu verwenden:

...
config disk
	option partition includeAllDisks
	option size '90%'
...

Den Daemon startet man über LuCI-Oberfläche neu, indem man zu System > Startup navigiert und beim Paket snmp den Restart-Button drückt.

Auf Grund des oben genannten Problems mit tmpfs-Partitionen erschien die gesuchten Informationen aber nie im SNMP-Baum.

Schlussendlich entschied ich mich für den Quick-und-Dirty-Ansatz. Ich ergänzte die crontab mittels

# crontab -e

mit folgendem Befehl:

...
0 4 * * *   rm -rf /tmp/beaker
...

Der Ordner wird nun pro-aktiv jede Nacht um 4 Uhr morgens zwangsweise gelöscht.

Dennoch hätte ich gerne die Möglichkeit, mittels Cacti den Zuwachs der Partition zu überwachen, um zu sehen, ob die Grösse stetig zunimmt, oder ob es einzelne Episoden mit plötzlichem Grosswachstum gibt.

Nachtrag

Allenfalls könnte man mit folgendem Script etwas basteln:

snmpd-tmpfs.sh

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

Keine Kommentare | neuen Kommentar verfassen

Dienstag, 11. Oktober 2016

SFP-Informationen unter Linux anzeigen

Weil ich meinen Fiber7 SFP-Transceiver im Turris Omnia (noch) nicht zum Laufen bringen konnte, habe ich mich schlau gemacht, wie man Informationen über diesen Hardwarebaustein mit Linux-Bordmitteln abfrägt.

Ein Knowledgebase-Artikel bei Cumulus Networks lotste mich zu ethtool.

Konkret (von der Cumulus Web-Site kopiert):

$ ethtool swp1
Settings for swp1:
        Supported ports: [ FIBRE ]
        Supported link modes:   1000baseT/Full
                                10000baseT/Full
        Supported pause frame use: No
        Supports auto-negotiation: No
        Advertised link modes:  1000baseT/Full
        Advertised pause frame use: No
        Advertised auto-negotiation: No
        Speed: 10000Mb/s
        Duplex: Full
        Port: FIBRE
        PHYAD: 0
        Transceiver: external
        Auto-negotiation: off
        Current message level: 0x00000000 (0)

        Link detected: yes

sowie noch viel spannender folgende SFP-spezifischen Informationen:

# ethtool -m swp1
swp1: SFP detected
    Connector : CopperPigtail
        EncodingCodes : Unspecified
    ExtIdentOfTypeOfTransceiver : GBIC/SFP defined by twowire interface ID
        LengthCable(UnitsOfm) : 1
    NominalSignallingRate(UnitsOf100Mbd) : 103
        RateIdentifier : Unspecified
    ReceivedPowerMeasurementType : OMA
        TransceiverCodes :
                SFP+CableTechnology : Passive Cable
    TypeOfTransceiver : SFP or SFP Plus
        VendorDataCode(yymmdd) : 110830
    VendorName : Amphenol
        VendorOUI : Amp
    VendorPN : 571540001
        VendorRev : M
    VendorSN : APF11350017C4V

Leider scheint ethtool auf dem Turris Omnia nicht standardmässig installiert zu sein:

root@TURRIS-OMNIA:~# which ethtool
root@TURRIS-OMNIA:~# 

Nachinstallieren kann man dieses, indem man unter System > Software das Paket ethtool herunterladen und installieren lässt:

turris-omnia-ethtool

Leider klappt es nicht wirklich, mittels dem Argument -m Informationen über Ethernet-Schnittstellen abzufragen:

# ethtool -m eth0
Cannot get module EEPROM information: Not supported

Links

Einige Hintergrundinformationen hier unter Phylink & SFP support

Tags: , , , ,
Labels: IT

Keine Kommentare | neuen Kommentar verfassen

Dienstag, 11. Oktober 2016

Turris Omnia: Erste Erfahrungen

Am Freitag, 7. Oktober 2016, wurde mir mein über Indiegogo ge-crowdfundeter Turris Omnia-Router ins Büro geliefert.

Am Sonntag-Abend ging ich mit dem Gerät online. Zeit für ein erstes Fazit:

Fiber7 SFP funktioniert (noch) nicht

Der Router wird mit einem SFP-Slot ausgeliefert. Optimal, dachte ich mir, so kann ich meinen Gerätedschungel lichten und den im Januar gekauften Fiber Media Converter TP-LINK MC220L auf’s Altenteil schicken.

Zu früh gefreut! Wie von mir im offiziellen Forum beschrieben und von Michael Stapelberg bestätigt funktioniert der flexOptix BIDI LX SFP Transceiver aktuell nicht im Router.

Zuerst ging ich (fälschlicherweise) davon aus, dass das Problem bei Turris zu suchen ist, doch ein Tweet von Fiber7 von heute Dienstag, 11. Oktober 2016, legt nahe, dass auf Seite ISP resp. auf Seiten des SFP-Herstellers noch etwas geändert werden muss:

Performance

Eigentlich hätte ich erwartet, dass der neue Router näher an die Schallgrenze (d.h. 1 GBit/s Down- und Upstream) herankommt. Doch mein stündlich laufendes Script, welches die Geschwindigkeit zu Init7s Ookla Geschwindigkeitsserver (Ookla Server ID 3026) misst, sagt etwas anderes aus:

ookla-init7-asus-rt-ac66u-turris-omnia

Links sieht man die Werte, die ich mit einem Asus RT-AC66U (Merlin-Firmware und mit deaktivierter Firewall) erzielt habe; rechts (nach dem Unterbruch) die Werte von Turris Omnia (mit aktivierter Firewall).

Beim Client handelt es sich um einen Intel NUC DC3217IYE, welcher mit einem Cat 5e-Kabel über einen 16-Port TP-LINK TL-SG1016D über ein 20m Cat 6 STP-Flachband-Kabel auf einen ZyXEL GS1100-8HP PoE Switch via ein Cat 5e-Kabel am Turris angeschlossen ist.

Ich gehe davon aus, dass die Performance höher wäre, wenn ich einen nicht so schmalbrüstigen Client verwenden würde. Und ja, die Firewall des Turris könnte ich ja eigentlich der Performance wegen auch deaktivieren. Doch mich reizt es, die Crowd-Firewall eingeschaltet zu belassen, um mich und mein Netzwerk besser vor Gefahren aus dem Internet zu schützen.

Doch das spielt hier keine Rolle, weil im Setup einzig der Router selber ausgewechselt wurde, der Rest blieb gleich.

Michael hingegen kommt der Schallmauer gefährlich nahe — 927 MBit/s:

Führe ich speedtest-cli (ein Python-Script) direkt auf dem Turris Omnia aus, erhalte ich folgende Werte:

# ./speedtest-cli --simple --server 3026
Ping: 4.704 ms
Download: 684.35 Mbit/s
Upload: 208.04 Mbit/s

CPU-Auslastung

Dank der Aufzeichnung der Vitalparameter des Routers mittels Cacti musste ich soeben feststellen, dass die beiden CPUs des Gerätes seit heute Mitternacht (sprich seit meinem zweiten, fehlgeschlagenen Test mit dem SFP-Transceiver) 100% beträgt. Auf beiden Cores:

turris-omnia-cpu-0-usage

turris-omnia-cpu-1-usage

Ein Login auf dem Router und htop zeigen, welche Prozesse die Last verursachen:

turris-omnia-socat-cpu-usage

Die Prozesse habe ich direkt in htop mittels F9 und SIGKILL abgeschossen (ein Neustart von socat im LuCI-Interface unter System > Software hat nichts gebracht). Jetzt ist die CPU-Auslastung im einstelligen Prozentbereich und die Load Average bereits bei 0.40.

LEDs

Natürlich dürfen frei konfigurierbare LED-Farben nicht den Ausschlag geben, ein Produkt zu kaufen. Dennoch möchte ich dies nicht mehr missen. Nun sehe ich nämlich von der Eingangstüre unserer Wohnung aus, ob der Router läuft (grünes LED für Power) und ob er mit dem Internet verbunden ist (rotes LED für WAN). Hinzu kommen weiss blinkende LEDs, die mir zeigen, dass im LAN Pakete herumgeschickt werden.

turris-omnia-leds

IPv6

Das Ding würde auch IPv6 unterstützen, doch mental, fähigkeitstechnisch und auf Grund meiner leicht komplexeren Netzwerk-Infrastruktur im LAN sehe ich mich derzeit nicht imstande, diesen Schritt bereits zu wagen. Gut zu wissen, dass Turris auf jeden Fall bereit wäre:

Usability

Verwirrend (und unschön) ist es, dass der Router über zwei Web-Oberflächen verfügt: Einerseits das von Turris Omnia selbst entwickelte Foris, welches einen Wizard, aber kaum Einstellungsmöglichkeiten bietet, andererseits das OpenWRT-LuCI-Interface, über welches man jedes hinterste Bit des Routers konfigurieren kann (oder so).

Das letztere Interface kannte ich so bereits von meinem TP-LINK TL-MR3020 Travel-Router, der mich auf Reisen überall hin begleitet. Ganz interessant ist hier der Paket-Manager des Turris, obwohl ich abgesehen von snmpd und ethtool noch kein Paket installiert habe. Die Bedienbarkeit dieses Interfaces ist aber nicht so simpel gehalten wie bei einem Consumer-Router und benötigt deshalb eine gewisse Einarbeitungszeit.

Nachtrag: Unboxing-Photos

Turris vom Flickr-Benutzer Doommeer

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

5 Kommentare | neuen Kommentar verfassen