Posts Tagged ‘Omnia’

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
image-7008

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
image-6997

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
image-6998

turris-omnia-cpu-1-usage
image-6999

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

turris-omnia-socat-cpu-usage
image-7000

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
image-7001

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

3 Kommentare | neuen Kommentar verfassen