Archiv der Kategorie: Code

LoRa Reichweite mit TTNmapper abschätzen

Nachdem wir jetzt auch einen Gateway fertig haben (ich werde in einem eigenen Beitrag berichten) und mehrere Sensoren funktionieren, wäre es doch mal interessant, die Reichweite der Signale kennenzulernen.

Grundsätzlich senden meine Sensoren bisher nur Messdaten, im Moment aber noch eher statische kurze Textmitteilungen. Was mir fehlt sind die GPS-Positionsdaten, damit ich feststellen kann, von welcher Position mit welcher Signalstärke Pakete empfangen wurden (RSSI).

Nachtrag Juli 2017: wir haben mit dem Aufbau einer Community bei The Things Network in Wien begonnen. Das Ziel ist die Schaffung eines freien und offenen Netzes für IoT. Nachdem ich mehrfach auf meinen Blog hin angeschrieben wurde, es den Personen aber nicht bewusst war, dass sich hier was tut, möchte ich auf folgende Links verweisen: folgt uns auf Twitter (@TTN_Vienna), für Updates und Infos zu den nächsten Treffen oder besucht die Wiener Community Seite!

Bevor ich mich damit beschäftige, mit dem LoRa/GPS Shield auch die GPS-Daten mitzusenden, möchte ich mit ttnmapper.org mal die GPS-Daten dazuschummeln. TTNmapper hat einen super Ansatz dafür gewählt: in der Annahme, dass ich mein Smartphone (Android) und meinen Sensor bei mir habe (mit mir herumtrage oder in meinem Fall beides mit dem selben Auto unterwegs ist), ergänzt TTNmapper mit einer eigenen App einfach die GPS-Position vom Smartphone. Clever!

Funktionsweise

Klarerweise muss ich auf meinem Android Smartphone die App aus dem Play Store installieren. Danach melde ich mich in der App mit meinen Login-Daten bei The Things Network an und wähle aus meinen Applikationen und Devices den Sensor aus, mit dem ich aktuell messen möchte. (Falls jemand seine Logindaten nicht bekanntgeben möchte, kann man auch direkt die Zugangsdaten für den MQTT-Zugang des Device eingeben, das ist natürlich viel umständlicher, aber man muss die Zugangsdaten nicht eingeben).

Ab sofort höre ich jedesmal, wenn ein Paket angekommen ist (die App erfährt das über MQTT wirklich sofort) einen Ton.

Also habe ich eine kleine Magnetfußantenne für 868 MHz neben meine APRS-Antenne auf’s Auto montiert und die App bei meiner heutigen Ausfahrt mitlaufen lassen. Die Stromversorgung über 12V Anschluss auf einen Verteiler mit USB-Hub war zum Glück für Amateurfunkzwecke schon vorhanden und musste ich nur mehr dazustecken.

Es hat super funktioniert! Beim Starten des Motors ist sofort das erste Klingeln am Smartphone hörbar gewesen.

Nach einer kurzen Ausfahrt hat sich folgendes Bild ergeben:

An die Farbgebung muss man sich noch gewöhnen, zum Glück ist eine Legende dabei. Die besten Signalstärken sind rot, die schlechtesten grün und türkis/blau.

Erfreulicher Weise hat mich auch der Gateway von Peter im 2. Bezirk ein paar Mal empfangen.

Zum Vergleich: links die heutige Route über APRS protokolliert und rechts die Punkte, an denen LoRa-Pakete angekommen sind:

LoRa TTN Gateway Pakete mit tcpdump mitprotokollieren

Über die Schnittstellen bei TTN (The Things Network) kann man eine Menge Daten auslesen – natürlich die Inhalte (Payload) der Applikationen und einige technische Werte.

Konkret interessiert mich zB. der RSSI (Eingangssignalstärke) der vom LoRa Gateway empfangenen Pakete. Im Webinterface kann man in der TTN Console im Bereich Gateway mitschauen und erhält hübsche JSON-Objekte, in denen alles enthalten ist. Ich habe aber keine Schnittstelle gefunden, mit der ich es auslesen kann – weder live noch nachträglich (als gespeicherte Werte).

Nachtrag Juli 2017: wir haben mit dem Aufbau einer Community bei The Things Network in Wien begonnen. Das Ziel ist die Schaffung eines freien und offenen Netzes für IoT. Nachdem ich mehrfach auf meinen Blog hin angeschrieben wurde, es den Personen aber nicht bewusst war, dass sich hier was tut, möchte ich auf folgende Links verweisen: folgt uns auf Twitter (@TTN_Vienna), für Updates und Infos zu den nächsten Treffen oder besucht die Wiener Community Seite!

Nachdem ich mir das Protokoll schon angeschaut habe, war mir klar, dass es die Daten unverschlüsselt überträgt. Es nutzt übrigens UDP für die Kommunikation zu den TTN Network Servern auf Port 1700.

Also habe ich meiner /etc/rc.local (vor dem „exit 0“!) folgenden Eintrag hinzugefügt:

/usr/sbin/tcpdump -Aq port 1700 >> /var/log/ttn-tcpdump-gateway.asc &

Damit wird nach jedem Reboot in die Datei /var/log/ttn-tcpdump-gateway.asc per tcpdump in ASCII die Inhalte aller Verbindungen zu Port 1700 gespeichert:

Mich interessieren eigentlich nur Übertragungen und Statusmeldungen. In beiden kommt „rx“ vor:

cat /var/log/ttn-tcpdump-gateway.asc | grep rx

Die Meldungen beginnen immer mit 41 Zeichen (Byte) Header, die kann man wegschneiden:

cat /var/log/ttn-tcpdump-gateway.asc | grep rx | cut -c 41-

Wenn nach „rxpk“, der Meldung für ein empfangenes Paket suche, erhalte ich nur Meldungen, die der Gateway über LoRa empfangen hat:

cat /var/log/ttn-tcpdump-gateway.asc | grep rxpk | cut -c 41-

Hier hat man nun je Zeile ein JSON-Objekt mit sämtlichen Details zur Kommunikation:

{"rxpk":[{"tmst":4242060820,"time":"2017-04-15T14:55:05.977557Z","chan":1,"rfch":1,"freq":868.300000,"stat":1,"modu":"LORA","datr":"SF9BW125","codr":"4/5","lsnr":-10.5,"rssi":-115,"size":24,"data":"QK4XASaAvxEBoUDxzpcOkO+F6T1TVsvg"}]}

wird zB. mit http://jsonviewer.stack.hu/ zu

{
  "rxpk": [
    {
      "tmst": 4242060820,
      "time": "2017-04-15T14:55:05.977557Z",
      "chan": 1,
      "rfch": 1,
      "freq": 868.300000,
      "stat": 1,
      "modu": "LORA",
      "datr": "SF9BW125",
      "codr": "4/5",
      "lsnr": -10.5,
      "rssi": -115,
      "size": 24,
      "data": "QK4XASaAvxEBoUDxzpcOkO+F6T1TVsvg"
    }
  ]
}

LoRa Sensor mittels Arduino und LoRa Shield

Über einen Freund bin ich vor ein paar Wochen auf das Thema LoRa bzw. LoRaWAN aufmerksam geworden.

Vor allem seit ich The Things Network (https://www.thethingsnetwork.org) kenne und somit über die Community eine Möglichkeit besteht, die Technologie sinnvoll zu nutzen, bin ich interessiert mich damit mehr zu beschäftigen.

Nachtrag Juli 2017: wir haben mit dem Aufbau einer Community bei The Things Network in Wien begonnen. Das Ziel ist die Schaffung eines freien und offenen Netzes für IoT. Nachdem ich mehrfach auf meinen Blog hin angeschrieben wurde, es den Personen aber nicht bewusst war, dass sich hier was tut, möchte ich auf folgende Links verweisen: folgt uns auf Twitter (@TTN_Vienna), für Updates und Infos zu den nächsten Treffen oder besucht die Wiener Community Seite!

Ein LoRa Sensor ist ein Endgerät, das über das LoRa-Protokoll in ein Netzwerk Informationen funkt. Empfangen werden die Pakete üblicherweise von einem Gateway. Bis zur Auswertung der Pakete sind noch Network Server und Application Server nötig, die in meinem Fall über TTN (The Things Network) bereitgestellt werden.

Da ich auch mit Freunden einen Gateway bauen möchte, brauchen wir natürlich einen LoRa Sensor, um unseren Gateway zu testen. Als günstige Variante habe ich Arduino + LoRa Shield für Arduino gefunden.

Nachtrag Juli 2017: wir haben mit dem Aufbau einer Community bei The Things Network in Wien begonnen. Das Ziel ist die Schaffung eines freien und offenen Netzes für IoT. Nachdem ich mehrfach auf meinen Blog hin angeschrieben wurde, es den Personen aber nicht bewusst war, dass sich hier was tut, möchte ich auf folgende Links verweisen: folgt und auf Twitter (@TTN_Vienna) für Updates und Infos zu den nächsten Treffen oder besucht die Wiener Community Seite!

Zutaten

Falls jemand entspannt an das Projekt herangeht und mit 5-6 Wochen Lieferzeit aus Shenzhen (China) kein Problem hat, gibt es das LoRa Shield auch kostengünstiger (€ 18,70 am 1.4.2017) über Tindie zu kaufen. Hier beachtet bitte, dass Shipping (+ € 6,12 nach Österreich) und ggf. Zoll dazukommen.

Bitte beachtet bei Bestellungen immer, dass ihr die 868 MHz-Variante auswählt! Nur diese darf in der EU betrieben werden bzw. wird hier funktionieren!

Von der Vorgehensweise halte ich mich an diese Anleitungen:

  1. ein tolles Youtube-Video, das genau den hier beschriebenen Aufbau erklärt: LoRa Node with Arduino and Dragino Shield connected to TTN LoRaWAN von Andreas Spiess
  2. Software (Arduino Sketch) „Hello World“ von https://github.com/SensorsIot/LoRa
  3. LMIC library von IBM, angepasst für Arduino: wird vom Arduino Sketch benötigt

Vielen Dank an die Kollegen von TTN Zürich, die diese Anleitungen und Programme zur Verfügung stellen!

Zusammenbau

Das LoRa Shield muss nun nur mehr auf den Arduino gesteckt werden. Die Antenne wird an den SMA-Anschluss geschraubt.

Konfiguration

Nun lädt man den Arduino Sketch („Hello World“, siehe Link oben) ins Arduino IDE und muss ein paar Werte anpassen. Dazu erstellt man eine „Application“ in der Console von TTN und legt ein Gerät („Device“) an. Eine Over-The-Air-Activation (OTAA) ist nicht möglich, daher muss man manuell ABP wählen und die Werte vom Webinterface abschreiben. Diese werden von TTN automatisch generiert.

  1. NWKSKEY: der Network Session Key muss im korrekten Format in die geschwungenden Klammern { } eingefügt werden.
  2. APPSKEY: ebenso der Application Session Key und zum Schluss die
  3. DEVADDR, also die Geräteadresse im korrekten Format.

TTN bietet im Webinterface übrigens die Werte bereits im richtigen Format an. Im Zweifelsfall muss man auf „< >“ klicken, dann werden die Werte in anderen Formaten dargestellt und können mit copy & paste übernommen werden. Das gewünschte Format ist „msb“.

Ansonsten musste ich keine weiteren Änderungen am Code durchführen.

Trotzdem habe ich den zu übertragenden Text von „HI“ auf „stefan test“ geändert: dazu habe ich die Payload in der Variable „message[]“ in Zeile 57 angepasst:

  // Payload to send (uplink)
  static uint8_t message[] = "stefan test";

Nun habe ich den Sketch kompiliert und auf den Arduino übertragen. Unmittelbar darauf hat er begonnen, alle 20 Sekunden kurz zu blinken, wodurch ich mich bestätigt gefühlt habe, dass es funktioniert und nun alle 20 Sekunden die Meldung „stefan test“ mittels LoRa übertragen wird.

Überprüfen am Gateway

Einen Gateway hatten wir parat und er hat sofort die Pakete empfangen. Über die „Traffic“ Funktion in der TTN Console kann man die ankommenden Pakete gleich sehen.

Man sieht hier mehrere Pakete, die im Abstand von ca. 25 Sekunden ankommen. Die Frequenz wechselt bei jedem Paket, weil mehrere Kanäle genutzt werden: 868,1 – 868,5 – 868,3 usw.

Folgendes JSON Objekt mit allen Details erhält man aus der TTN Console beim Gateway Traffic:

{
  "gw_id": "eui-b827ebfffe6f377d",
  "payload": "QI4cASaAaAABhVJosx+GBwUwHBqp4DGG",
  "f_cnt": 104,
  "lora": {
    "spreading_factor": 9,
    "bandwidth": 125,
    "air_time": 205824000
  },
  "coding_rate": "4/5",
  "timestamp": "2017-03-29T05:57:06.352Z",
  "rssi": -25,
  "snr": 11.2,
  "dev_addr": "26011C8E",
  "frequency": 868100000
}

Es enthält sämtliche Details zur Übertragung. Ein paar Werte möchte ich kurz hervorheben:

  • gw_id: zeigt die ID des Gateways, der das Paket empfangen hat
  • payload: sind die übertragenen Daten in verschlüsselter Form
  • f_cnt: ist der Counter und gibt die Anzahl der Pakete wider
  • lora.spreading_factor: zeigt hier den Spreading Factor 9, der im Sketch eingestellt ist
  • rssi: zeigt die Signalstärke des empfangenen Pakets am Gateway an (hier: -25 dbm)
  • snr: das Signal/Rausch-Verhältnis
  • dev_addr: die Geräteadresse, die von TTN vergeben wurde und ich als DEVADDR im Sketch hinterlegt habe.
  • frequency gibt die Frequenz in Hertz an

Wir sehen, dass das Paket einwandfrei übertragen wurde und sogar sehr gut (-25 dbm) empfangen wurde. Bei diesem Test war der Abstand vom Sensor zum Gateway aber auch im Bereich von 5 Metern.

Optimierungen

Als Spreading Factor ist 9 eingestellt. Um die Reichweite zu erhöhen, kann man auch zB. SF12 einstellen. Das geht im Arduino Sketch auf Zeile 90:

  // Set data rate and transmit power for uplink (note: txpow seems to be ignored by the library)
  LMIC_setDrTxpow(DR_SF9, 14);

Falls man die Pakete weniger oft übertragen möchte (alle 20 Sekunden ist zum Testen super, aber dauerhaft verbraucht es zu viel Airtime), kann das in Zeile 39 anpassen:

// Schedule TX every this many seconds (might become longer due to duty
// cycle limitations).
const unsigned TX_INTERVAL = 20;

Ubuntu Linux per SNMP in LibreNMS einbinden

Neuerdings bin ich ein Fan von LibreNMS, einem Network Management System bzw. einer Open-Source-Lösung für System Management.

Installation von LibreNMS

Installiert habe ich LibreNMS nach dieser Anleitung von Oliver Marshall, das hat auf Anhieb super geklappt: http://olivermarshall.net/how-to-install-librenms-on-ubuntu/

Nach der Installation habe ich vor allem Router, Switches und sonstiges Netzwerkequipment eingebunden, das hat super funktioniert. SNMP ist dort meist recht einfach konfigurierbar, ältere Geräte haben nur SNMPv1 akzeptiert, bei neueren klappt’s dann auch mit SNMPv2c und SNMPv3.

Nun möchte ich Linux Server, meist Ubuntu und meist Virtuelle Maschinen, einbinden.

Aktiviere SNMP am Ubuntu Server

Die Server müssen natürlich vom LibreNMS erreichbar sein. SNMPd, also der Daemon (= Dienst), der SNMP-Verbindungen entgegennimmt und beantwortet ist standardmäßig nicht installiert.

Mittels

apt-get update
apt-get install snmpd

ist das schnell erledigt.

Nun antwortet der SNMP-Server jedoch nur auf lokale Anfragen (vom eigenen Host (localhost) bzw. der IP-Adresse 127.0.0.1). Außerdem muss man eine SNMP-Community wählen. Eine SNMP-Community entspricht im weiteren Sinne einem Passwort. Standardmäßig ist meist „public“ für lesenden Zugriff (Read-Only) und „private“ für Schreibzugriff (Read+Write) konfiguriert. Diese Werte müssen unbedingt geändert werden.

Konfiguration SNMPd

Um snmpd zu konfigurieren, öffne ich die Datei /etc/snmp/snmpd.conf:

und ändere folgende Zeilen:

agentAddress  udp:161
rocommunity MeineGeheimeCommunity default -V systemonly
rocommunity6 MeineGeheimeCommunity default -V systemonly

Mit den oben getätigten Einstellungen nimmt der SNMPd nun Verbindungen von allen IPv4-Adressen an, wenn diese über die Community „MeineGeheimeCommunity“ anfragen.

Damit auch die Location und der Kontakt korrekt über SNMP mitgeteilt werden, passe ich diese in der gleichen Konfigurationsdatei an:

sysLocation    mein_Standort
sysContact     meine@email.adresse

Einbindung in LibreNMS

Nun kann ich über das Menü „Devices“ und „Add Device“ den Linux Server einbinden:

Kurz darauf erscheint der Server in der Liste und LibreNMS sammelt Daten. Nach einigen Stunden hat man dann bereits aussagekräftige Grafiken.

Firewall

Nachdem wir hier den SNMPd so installiert haben, dass dieser allen IP-Adressen (auch aus dem Internet) antworten würde und der einzige Schutz die Community ist, empfehle ich eine lokale Firewall zu installieren, die den Port 161 für UDP schützt und nur vom LibreNMS-Server zulässt.

Eine Anleitung dazu findet ihr hier: http://awesomism.co.uk/allow-snmp-using-ufw-on-ubuntu-server-12-04/

APC USV mit Raspberry überwacht

Auch ein Projekt, das ich schon lange umsetzen wollte: ich möchte eine USV installieren, um bei einem Stromausfall die Netzwerkverbindungen (Internet!) über Funkfeuer aufrecht zu halten. Es sollen

  • das Funkfeuer-Equipment am Dach,
  • mein Switch,
  • der Router
  • und ein Access Point

abgesichert werden.

Die Anforderungen an die Leistung sind also recht gering (jedenfalls weit unter 100W), daher dachte ich mir, dass eine günstigere USV ausreichen müsste.

Gleichzeitig habe ich nicht die Anforderung, dass ein Server oder NAS bei einem Stromausfall heruntergefahren werden muss. Es handelt sich rein um Netzwerkgeräte, die einfach abgeschaltet werden können sobald die Akkus leer sind und auch wieder zuverlässig starten sobald sie wieder Strom erhalten.

Ich habe also die APC Backup-UPS ES 700 mit 700 VA um weniger als € 90,- gekauft.

Die wesentlichen Entscheidungspunkte waren:

  • namhafter Hersteller,
  • ausreichend Kapazität (700 VA),
  • Schuko-Steckdosen in ausreichender Anzahl,
  • ausgesprochen preiswert und
  • last but not least: sie kann über ein USB-Kabel überwacht werden und ist kompatibel zu gängigen Standards.

Inbetriebnahme

Die USV war rasch in Betrieb genommen. Es muss nur ein Kabel an die Batterie im Batteriefach angeschlossen werden und dann steckt man die USV an die Steckdose. Fertig!

Über zwei LEDs (grün und rot) signalisiert die USV den Zustand und mögliche Defekte.

Überwachung

Es wäre nicht meine Art, die USV einfach vor sich hinlaufen zu lassen und darauf zu hoffen, dass alles in Ordnung ist. Es müssen also eine Überwachung der Funktion sowie ein paar Statistiken her.

Die Daten kann man von der USV über USB abrufen. Server habe ich keinen in der Nähe, also habe ich mich entschieden einen Raspberry Pi der ersten Generation (der schon einige Monate ohne Auftrag herumkugelt) für diese Funktion einzusetzen.

apcupsd auf Raspberry Pi

Als Basissystem habe ich Debian Jessie in der Minimalinstallation (ohne grafischer Oberfläche) gewählt. Mittels

apt-get install apcupsd

ist der Daemon schnell installiert.

Zwei Konfigurationsdateien müssen dann noch angepasst werden:

Die hauptsächliche Konfiguration wird in der Datei /etc/apcupsd/apcupsd.conf vorgenommen. Ich habe nur folgende Zeilen angepasst:

UPSCABLE usb
UPSTYPE usb
DEVICE

Die Zeile „DEVICE“ bleibt bewusst ohne weitere Angabe. Das ist beim USBTYPE „usb“ so vorgesehen. Damit wird die USV automatisch erkannt.

In der Datei /etc/default/apcupsd muss ISCONFIGURED auf „yes“ gesetzt werden, damit der Dienst (beim Booten) startet.

ISCONFIGURED=yes

Nach dem Aufruf von“service apcupsd start“ startet der Daemon.

Mittels „apcaccess status“ kann auch sofort der Status der USV abgerufen werden:

pi@upsberry:~ $ apcaccess status
APC      : 001,035,0906
DATE     : 2016-12-30 14:58:11 +0100
HOSTNAME : upsberry
VERSION  : 3.14.12 (29 March 2014) debian
UPSNAME  : upsberry
CABLE    : USB Cable
DRIVER   : USB UPS Driver
UPSMODE  : Stand Alone
STARTTIME: 2016-12-30 10:53:17 +0100
MODEL    : Back-UPS ES 700G
STATUS   : ONLINE
LINEV    : 228.0 Volts
LOADPCT  : 0.0 Percent
BCHARGE  : 100.0 Percent
TIMELEFT : 38.4 Minutes
MBATTCHG : 5 Percent
MINTIMEL : 3 Minutes
MAXTIME  : 0 Seconds
SENSE    : Medium
LOTRANS  : 180.0 Volts
HITRANS  : 266.0 Volts
ALARMDEL : 30 Seconds
BATTV    : 13.5 Volts
LASTXFER : Unacceptable line voltage changes
NUMXFERS : 1
XONBATT  : 2016-12-30 10:56:54 +0100
TONBATT  : 0 Seconds
CUMONBATT: 53 Seconds
XOFFBATT : 2016-12-30 10:57:47 +0100
STATFLAG : 0x05000008
SERIALNO : 5B16xxx
BATTDATE : 2016-08-05
NOMINV   : 230 Volts
NOMBATTV : 12.0 Volts
FIRMWARE : 871.O4 .I USB FW:O4
END APC  : 2016-12-30 14:58:53 +0100

Alarmierung per Email

Beispiel einer Email-Benachrichtigung nach Ausfall der Netzspannung

Wie beschrieben benötige ich keine weiteren Maßnahmen bei einem Stromausfall. Es muss also kein Server oder NAS runtergefahren werden. Ich möchte aber schon ein Email erhalten, das mir eine Statusänderung mitteilt.

In meinem Fall habe ich einen lokalen Mailserver installiert, der die Emails direkt zustellt (ohne Smarthost bzw. nicht über einen anderen SMTP-Server).

apt-get install sendmail

Um den Emailversand zu aktivieren, gehören zwei Zeilen in der /etc/apcupsd/apccontrol angepasst:

export SYSADMIN=stefan@schultheis.at
export APCUPSD_MAIL="/usr/sbin/sendmail"

Nach dem Neustart des apcupsd habe ich die USV von der Stromversorgung getrennt und kurz darauf ein Email mit der Warnmeldung „UPS Power Failure!!!“ erhalten.

Webinterface

upsstats.cgi

Für die Anzeige von Statistiken am Webinterface gibt es vier CGIs:

  • multimon.cgi: hier wird übersichtlich der Status angezeigt. Das ist vor allem sinnvoll, wenn mehrere USVs von einem Daemon überwacht werden sollen:
    apcupsd multimon.cgi – alles OK

    apcupsd multimon.cgi – Ausfall der Stromversorgung
  • upsstats.cgi: detaillierte Statistik zu einer USV (siehe Screenshot oben)
  • upsfstats.cgi: textbasierter Output, wie beim CLI Tool „apcaccess status“ (siehe oben)
  • upsimage.cgi: hat bei mir nicht funktioniert

Installiert ist das Ganze recht einfach:

apt-get install apcupsd-cgi apache2
a2enmod cgi

Hiermit wird ein Apache Webserver installiert (falls nicht schon vorhanden) und die CGIs im Verzeichnis /usr/lib/cgi-bin/ hinterlegt. Über das a2enmod-Kommando wird CGI am Webserver aktiviert.

Ab sofort kann man mit dem Webbrowser die Statistiken zur USV abrufen. Da der Webserver nur vom internen LAN (nicht im Internet) erreichbar ist und auch auf dem Server keine weiteren Dienste laufen, habe ich mir die index.html im /var/www/html-Verzeichnis mit folgenden Einträgen überschrieben, um die CGIs gemütlich aufrufen zu können:

<title>APC USV Vorzimmer</title>
<body>
<a href="/cgi-bin/apcupsd/multimon.cgi">
apcupsd MultiMon
</a><br>
<a href="/cgi-bin/apcupsd/upsstats.cgi">
apcupsd Stats
</a><br>
<a href="/cgi-bin/apcupsd/upsfstats.cgi">
apcupsd fStats
</a><br>
<a href="/cgi-bin/apcupsd/upsimage.cgi">
(apcupsd Image)
</a>
</body>

 

speedtest.py für Ubiquiti EdgeRouter

Vor kurzem habe ich einen Beitrag über speedtest-cli verfasst, weil man damit Speedtests auf der Kommandozeile von Ubiquiti EdgeRoutern oder EdgePoints automatisieren kann.

Hinweis: im ursprünglichen Beitrag zu diesem Tool sind die Möglichkeiten genauer beschrieben. Ich empfehle, auch einen Blick dorthin zu riskieren.

Ich erstelle beispielsweise jeden Tag in der Früh einen Report über die Geschwindigkeiten auf meinen Funkfeuer-Standorten. Den Report erhalte ich per Email und kann daran die Performance der weit entfernten Standorte erkennen.

Seit kurzem ist speedtest-cli allerdings durch speedtest.py abgelöst worden. Das Tool speedtest.py wurde vom gleichen Developer entwickelt. Es erscheint beim Aufruf von speedtest-cli folgende Meldung:

The file speedtest_cli.py has been deprecated in favor of speedtest.py

Details zu speedtest.py sind weiterhin hier zu finden: https://github.com/sivel/speedtest-cli

Es kann über folgende Kommandos installiert werden (analog zur bisherigen Anleitung, aber natürlich von anderer Quelle):

curl -o /config/user-data/speedtest.py https://raw.githubusercontent.com/sivel/speedtest-cli/master/speedtest.py
chmod u+x /config/user-data/speedtest.py

gestartet wird ein Test entsprechend über folgenden Aufruf:

/config/user-data/speedtest.py

Es gibt einige praktische Kommandozeilenoptionen, die haben sich durch das Update nicht verändert und habe ich im ursprünglichen Blogbeitrag ausführlicher vorgestellt.

Speedtest über Ubiquiti Edgerouter CLI

Ich betreibe mehrere Standorte, die im Wiener Funkfeuer-Netz verteilt sind. Mich interessiert die Performance (vor allem die Bandbreite vom bzw. zum Internet), die ja abhängig von Tages- oder Jahreszeit schwanken kann.

Update Dezember 2016: das Tool speedtest-cli ist durch speedtest.py, das vom gleichen Entwickler geschrieben wurde und die gleichen Möglichkeiten bietet, abgelöst worden. Die Installation ist daher abweichend. Ich habe die neue Vorgehensweise in einem neuen Beitrag erklärt. Die hier beschriebenen Optionen und Möglichkeit haben jedoch weiterhin Gültigkeit.

Bisherwar ich recht erfolgreich mit Bandbreite iPerf. Dazu benötige ich aber zwei Geräte, zwischen denen dann die Bandbreite gemessen wird – das ist die richtige Methode, wenn man zB. eine Funk-Verbindung zwischen zwei Geräten messen möchte. Aber wenn ich die Internet-Performance messen möchte, muss ich zwei Geräte bedienen.  Die Ergebnisse sind dafür belastbar, sind nachvollziehbar/plausibel und spiegeln die erlebte Performance wider.

Wenn ich vor Ort bin, nutze ich die Speedtest-App (hier der Link für iOS/iPhone/iPad) von Ookla Speedtest.net oder den RTR Netztest (auch für iOS/iPhone/iPad). Diese App gefällt mir in letzter Zeit sogar besser, weil auch viele andere Werte geprüft werden.

Für die Ubiquiti EdgeRouter oder Ubiquiti EdgePoints, die wir in letzter Zeit gerne einsetzen, gibt es da eine einfache Möglichkeit:

Installation: Speedtest für CLI

Heute haben mir Freunde ein Messergebnis geschickt, das eindeutig über die CLI gemessen wurde. Dabei ist mir die Idee gekommen, auch meine EdgeRouter (und EdgePoints, also die Outdoor-Variante) damit auszurüsten und in Zukunft selbst gemütlich über die CLI testen zu können. Also hab‘ ich mir das gleich angesehen:

Auf Github findet man das Python Script speedtest-cli: https://github.com/sivel/speedtest-cli

Man benötigt nur das .py-Script, das recht einfach am EdgeRouter heruntergeladen werden kann. Damit es auch nach einem Update des Routers verfügbar bleibt, speichere ich es in /config/user-data:

curl -o /config/user-data/speedtest_cli.py https://raw.githubusercontent.com/sivel/speedtest-cli/master/speedtest_cli.py

(Weil wget im Standard-Image nicht installiert ist, verwende ich curl -o. Weil unzip nicht verfügbar ist, lade ich das .py-Script vom letzten master-Branch raw von github).

Danach markiere ich das Script als ausführbar:

chmod u+x /config/user-data/speedtest_cli.py

Und schon kann’s losgehen, ich starte einen Speedtest mittels:

/config/user-data/speedtest_cli.py

Das Ergebnis überzeugt mich:

speedtest_cli1

Optionen

Es gibt noch ein paar erwähnenswerte Optionen zu dem Tool. Vor allem –simple könnte zB. für Scripts interessant sein:

–simple zeigt nur den Output an: Ping/RTT, Download- & Uploadraten.

/config/user-data/speedtest_cli.py --simple

ergibt:

Ping: 26.968 ms
Download: 38.36 Mbit/s
Upload: 27.19 Mbit/s

speedtest_cli2–share liefert eine URL zurück, bei der das Ergebnis grafisch dargestellt wird:

–server SERVER-ID nutzt den Zielserver mit der entsprechenden ID. Diese kann man in der Liste aller verfügbaren Server finden, welche  mittels –list abgerufen wird

–secure nutzt https statt http für die Test

–version liefert die Versionsnummer zurück

OLSRd (RFC3626) EdgeRouter Installation

olsrd-pinguinDamit man Ubiquiti EdgeRouter und Ubiquiti EdgePoint-Geräte im Netz von Funkfeuer Wien als Router betreiben kann, ist es notwendig, einen dynamischen Routing Daemon zu installieren. Bei Funkfeuer Wien ist das aktuell OLSRd (Open Link State Routing Daemon in Version 1). Dieser erkennt über zB. Funkstrecken die Router an den Gegenstellen und tauscht IP-Adressdaten aus, damit man selbst erreichbar ist und auch das Internet oder andere Standorte erreichen kann. Dieser Routing Daemon funktioniert sowohl für IPv4 als auch IPv6. Nähere Informationen zur Funktionsweise von dynamischem bzw. adaptivem Routing findet man bei Wikipedia.

Installation

Um die Installation möglichst einfach zu gestalten, hat Christoph Lösch, ein engagierter Kollege von Funkfeuer Wien, einen Wizard erstellt. Dieser Wizard kann über das Webinterface der EdgeRouters installiert und konfiguriert werden und stellt alle benötigten Funktionen und Optionen zur Verfügung.

Zum Download steht der Wizard auf github bereit. Die jeweils aktuellste Version findet ihr hier:
https://github.com/vchrizz/ER-wizard-OLSRd_V1/releases/latest

Installiert wird der Wizard, indem man am EdgeRouter auf den Tab „Wizards“ klickt und danach das „+“ bei „Feature Wizards“ klickt. Dort kann man die Version hochladen, die man bei Github gefunden hat und als Namen zB. „OLSRd_V1“ vergeben. Unter diesem Namen scheint der Wizard dann auch auf.

Seit Version 1.3 (Update 3, u3 vom Oktober 2016) enthält der Wizard auch die olsrd-Pakete. Davor musste man diese separat hochladen, oder den Router online bringen, damit der Wizard die Pakete selbst vom Internet nachlädt.

olsrd-wizardNach der Installation sieht man beim „Package Status“ hoffentlich zwei „Success“-Meldungen: eine für den Routing Daemon selbst (olsrd) und eine für die Plugins (olsrd-plugins). Mit den Plugins ist es möglich, Informationen über das Routingprotokoll zB. per http abzurufen.

Sofern alles geklappt hat, kann man nun folgende Optionen anhaken:

  • Setup Script,
  • Enable OLSR daemon,
  • Run OLSR daemon (on boot, if enabled)
  • und das bzw. die Interface(s) wählen, bei denen OLSRd aktiv sein soll. Das sind in der Regel die Interfaces mit den öffentlichen IP-Adressen.
    Bitte aktiviert OLSRd nicht auf den privaten IPs, da diese sonst auch im Netz geroutet werden.

Die gleichen Optionen wählt man (bei Bedarf) auch für IPv6.

Danach klickt man auf „Restart OLSR daemon(s) on ‚Apply'“, damit die Änderungen auch vom Routingprozess übernommen werden und wählt „Apply“. Kurze Zeit später sollte der Router online sein.

olsrd-pluginÜberprüfen kann man das über die OLSRd Plugins, zB. httpinfo (wenn aktiviert) über die IP des Routers und Port 8080 für IPv4 oder Port 8081 für IPv6. Falls dort nichts antwortet, prüft bei den Einstellungen des Wizards, ob die entsprechenden Plugins auch aktiviert sind.

Setup Script

Im Zuge der Installation haben wir die Option „Setup Script“ aktiviert. Ich empfehle, das dauerhaft aktiviert zu lassen. Dadurch prüft der Wizard bei jedem Reboot, ob die olsrd-Pakete ordentlich installiert sind bzw. würde sie ggf. neu installieren. Das ist zum Beispiel bei einem Upgrade des Images des EdgeRouters nötig – der Wizard bleibt nach einem Upgrade erhalten, aber die olsrd-Pakete sind nicht mehr installiert; das erledigt das Setup-Script beim ersten Bootvorgang mit der neuen EdgeOS-Version.

Wizard updaten

Da Christoph und die Community fleißig neue Funktionen integrieren und ggf. auch neue Versionen von olsrd mit Bugfixes oder sicherheitsrelevante Updates erscheinen, könnte es sinnvoll sein, den Wizard zu aktualisieren und damit die Umgebung up-to-date zu halten.

Der Vorgang dafür ist sehr einfach: den Wizard mittels des Buttons „Delete From List“ ganz unten in den Wizard-Optionen entfernen und gleich darauf die neue Version installieren.

Modelle

Getestet habe ich den Wizard mit folgenden EdgeRoutern:

Der Wizard soll auch auf anderen EdgeRouter-Modellen funktionieren, da er die Plattform (mips vs. mipsel) selbstständig erkennt und korrekt installiert.

Mehr zu dem Thema

gibt es hier:

Lösungsvorschläge für den Ubiquiti AirOS AiRMAX Hack vom Mai 2016 im Netz von Funkfeuer Wien

airoslogin-motherAm 13. +14. Mai 2016 wurde eine Sicherheitslücke (vmtl. im Webserver) der Ubiquiti Airmax Antennen mit AirOS Software ausgenutzt. Die Gesamtzahl der Standorte ist von etwa 230 aktiven Knoten auf knapp mehr als 150 Nodes zurückgegangen, die  unmittelbar nach der Attacke noch online waren. Mittlerweile geht die Zahl zum Glück wieder nach oben.

Aus jetziger Sicht platziert der Hack einige Dateien unter /etc/persistent. Außerdem werden die Login-Daten überschrieben und SSH-Keys installiert, mit denen ein Hacker von außen weiterhin auf die Antenne zugreifen kann.

Sollten Spuren des Hacks auf einer Antenne auftauchen, ist es jedenfalls empfehlenswert, per TFTP ein Image neu zu laden und die Antenne neu zu konfigurieren. Die Vorschläge weiter unten in diesem Text sind eher als Sofortmaßnahme gedacht, um die Antennen rasch wieder online zu bekommen.

Auswirkungen / Festellen des Hacks

Ich habe zwei Auswirkungen des Problems auf meinen Antennen festgestellt:

  • Großteils sind die Antennen auf Werkseinstellungen zurückgesetzt und daher über 192.168.1.20 mit Username „ubnt“ und Passwort „ubnt“ erreichbar. Eine Veränderung an den Antennen konnte ich nicht feststellen, wodurch das Einspielen eines Backups bzw. eine Neukonfiguration das Problem rasch löst. Idealerweise flasht man die Antenne per TFTP neu. Leider muss man diese Schritte vmtl. vor Ort durchführen, also hinfahren…
  • ubnt-hackManche Antennen sind noch online, aber ich kann mich nicht mehr mit dem bekannten Passwort anmelden. Wenn die Antenne „erfolgreich“ gehackt ist, wurden Username + Passwort auf „mother“ und „fucker“ geändert. Mein „ubnt“-User hat nicht mehr funktioniert, obwohl er in der /etc/passwd noch enthalten ist. Seit dem Entfernen des Hacks funktioniert mein ubnt-User wieder normal. Das Passwort ändert man zur Sicherheit trotzdem.
    Im Verzeichnis /etc/persistent/ findet man außerdem mehrere Files als Hinweis auf den Hack. Diese Antenne ist somit vom Virus befallen und muss gesäubert werden!

Details zum Hack

Details findet ihr im Forum von Ubiquiti Networks. Aktuell beginnen auch erste Händler entsprechende Hinweise zu posten:

Lösungsstrategien

Zuerst muss man feststellen, ob sich die Antenne im Werkszustand befindet oder nicht. Wenn sie über 192.168.1.20 mit Username „ubnt“ und Passwort „ubnt“ per Webbrowser erreichbar ist, kann man wie gewohnt die Konfiguration durchführen bzw. ein Backup einspielen. Besser ist es, zur Sicherheit per TFTP neu zu flashen. Dann kann man wirklich davon ausgehen, dass kein Schadcode erhalten bleibt.

Wichtig: zum Abschluss muss die Firewall konfiguriert werden, sodass Zugriffe über http und https nur von vertrauenswürdigen IP-Adressen möglich sind. Siehe dazu „Konfiguration der Firewall“.

Entfernen des Virus

Falls die Antenne erreichbar ist, gehört unbedingt geprüft, ob der bisherige Login noch funktioniert. Wenn die Antenne gehackt wurde, muss man ab sofort mit den Daten des Hackers, Username „mother“ und Passwort „fucker“, einloggen.

Es gibt ein Removal Tool, das auf Java basiert, von Ubiquiti zum dem Problem: https://community.ubnt.com/t5/airMAX-General-Discussion/Virus-attack-URGENT-UBNT/m-p/1563869

Alternativ gibt es auf Github ein Script, das aber auch den Standard-Port des Webserver auf 81 setzt: https://github.com/diegocanton/remove_ubnt_mf/

Update 16.5.2016: angeblich verbleiben ein paar ipks installiert, es ist somit ein Reset auf Werkseinstellungen (noch besser: per TFTP neu flashen) dem Entfernen/desinfect-Script zu bevorzugen, siehe auch: https://lists.funkfeuer.at/pipermail/wien/2016-May/012228.html

Update 17.5.2016: Ubiquiti stellt eine Android App – ein Virus Removal Tool – zur Verfügung: https://play.google.com/store/apps/details?id=virusfixer.ubnt.com.ubntvirusremoval

Ich habe mir erlaubt, das desinfect.sh-Script (Ausgangspunkt ist commit #c841d87) von Github zu übernehmen und einige Funktionen anzupassen, damit es für meine Zwecke passt.

Funktionsübersicht:

  • das Script wird lokal auf der Antenne über SSH ausgeführt.
  • das Script überprüft, ob die Antenne infiziert ist.
  • die infizierten/veränderten Files werden gelöscht
  • die Accounts für „mcad“, „mcuser“ und „mother“ in /etc/inittab und /etc/passwd werden gelöscht
  • die Änderungen werden persistent gespeichert
  • Prozesse des Hacks werden gekillt
  • wichtig: danach muss die Firewall (siehe unten) konfiguriert und rebootet werden!

Das angepasste Script findet ihr unten und zum Download hier:

#!/bin/sh
# This script removes the Ubiquiti AirOS hack
# Script is based on this work:
# https://github.com/diegocanton/remove_ubnt_mf
# Colaboration: Alexandre Jeronimo Correa - Onda Internet, PVi1 (Git user)
# modified 2016/05/16 by Stefan Schultheis
FILE=/etc/persistent/mf.tar

# Check virus
if [ -e "$FILE" ] ; then
    echo "Infected :("
    #Access folder
    cd /etc/persistent
    #Remove the virus
    rm mf.tar
    rm -Rf .mf
    rm -Rf mcuser
    rm rc.poststart
    rm rc.prestart
    #Remove mcuser in passwd - by Alexandre
    sed -ir '/mcad/ c ' /etc/inittab
    sed -ir '/mcuser/ c ' /etc/passwd
    sed -ir '/mother/ c ' /etc/passwd
    #Write new config
    cfgmtd -w -p /etc/
    #Kill process - by Alexandre
    kill -HUP `/bin/pidof init`
    kill -9 `/bin/pidof mcad`
    kill -9 `/bin/pidof init`
    kill -9 `/bin/pidof search`
    kill -9 `/bin/pidof mother`
    kill -9 `/bin/pidof sleep`
    echo "Clear Completed :)"
else
    echo "Clear :) No actions"
    exit
fi

Wichtig: zum Abschluss muss die Firewall konfiguriert werden, sodass Zugriffe über http, https und ssh nur von vertrauenswürdigen IP-Adressen möglich sind. Siehe dazu „Konfiguration der Firewall“.

Achtung bei Upgrade zu AirOS 5.6.5

Ubiquiti scheint ein Upgrade zu AirOS 5.6.5 zu empfehlen. Hier ist zu beachten, dass es

  1. keine Unterstützung für den Routing-Daemon OLSRd dort gibt,
  2. keine Custom Scripts (/etc/persistent/rc.*) mehr gibt! Dadurch kann die bestehende Funktion eingeschränkt sein!

Konfiguration der Firewall

Ich schalte mir nur einzelne IP-Adressen für den Zugriff auf die Webinterfaces frei, das mache ich mit folgenden iptables-Regeln. Hier werden künftig nur mehr Zugriffe aus 78.41.113.x und 78.41.113.y zugelassen (bitte eigene IPs einsetzen).

touch /etc/persistent/rc.poststart
echo "iptables -F" >> /etc/persistent/rc.poststart
echo "iptables -A INPUT -s 78.41.113.x -j ACCEPT" >> /etc/persistent/rc.poststart
echo "iptables -A INPUT -s 78.41.113.y -j ACCEPT" >> /etc/persistent/rc.poststart
echo "iptables -A INPUT -p tcp --dport 80 -j DROP 2>/dev/null" >> /etc/persistent/rc.poststart
echo "iptables -A INPUT -p tcp --dport 443 -j DROP 2>/dev/null" >> /etc/persistent/rc.poststart
echo "iptables -A INPUT -p tcp -i lo --dport 443 -j DROP 2>/dev/null" >> /etc/persistent/rc.poststart
cfgmtd -w -p /etc/

Ich empfehle darüber nachzudenken, ob man nicht die Erreichbarkeit von SSH ebenfalls auf ein paar weniger IPs beschränken möchte.

Nach einem Reboot ist die Antenne nur mehr von den oben eingetragenen IPs erreichbar.