Archiv der Kategorie: App

Allgemein, App, Code, fhem, Hausautomatisierung, Linux, Smartphone, WLAN

IoT und Hausautomatisierung mit Sonoff

2 Kommentare

Vor einigen Monaten bin ich von einem Freund auf die Produkte von Sonoff aufmerksam geworden. Die Geräte von Sonoff sind sehr preiswert und ermöglichen das Schalten von Verbrauchern, Auslesen von Sensorwerten und Messwerten.

Das Besondere dabei: die Geräte nutzen WLAN für die Kommunikation. Dafür wird der ESP8266 Chip verwendet, den viele schon aus der IoT („Internet of Things“)-Welt kennen. Es gibt neben der Sonoff-Software auch alternative Open Source-Projekte, mit denen die Geräte unabhängig von der „Sonoff-Cloud“ betrieben werden können. Beispielsweise verwende ich die TASMOTA-Software, um meine Sensoren und Aktoren von Sonoff mit FHEM zu nutzen. Der Austausch der Informationen funktioniert dabei mittels MQTT, wodurch man sehr flexibel ist – auch bei der Integration mit anderen Systemen.

Kurzer Überblick

Die Sonoff-Produkte senden ihre Daten entweder über ein eigenes Protokoll im 433-MHz-Bereich oder über WLAN. Ich konzentriere mich hier auf die WLAN-Nutzung, da sich damit für mich mehr Anwendungen realisieren lassen.

Schalter

Zum Schalten von 230 Volt-Endgeräten gibt es mehrere Möglichkeiten:

Schalter mit Messfunktion

Diese Produkte ermöglichen das Schalten abhängig von Temperatur und Luftfeuchtewerten bzw. melden den Energieverbrauch.

Für die Nutzung der Temperatur- & Luftfeuchtemessung gibt es drei Sensoren, die an den TH10 oder TH16 angeschlossen werden:

  • DS18B20: Außensensor aus rostfreiem Stahl
  • AM2301: Innensensor mit Temperatur- & Luftfreuchtesensor
  • Si7021: Innensensor mit hochpräzisem Temperatur- & Luftfreuchtesensor

Touch

Mit diesen kapazitativen Schaltern kann man Kommandos an die Haussteuerung senden oder Schalter bedienen.

Es gibt noch etliche weitere Produkte von Sonoff. Stöbert doch einfach mal! Beim Kauf empfehle ich darauf zu achten, ob das Teil über WLAN oder 433 MHz zu betreiben ist, damit alle Produkte zueinander kompatibel sind.

Software / Firmware

Falls ihr die Geräte werden nach dem Kauf mit der Original-Software betreiben möchtet, gibt es eine entsprechende Smartphone-App für die Konfiguration. Die Daten landen in der Sonoff-Cloud und können dort mit Diensten wie zB. Alexa oder IFTTT verknüpft werden. Natürlich ist man hier von der Cloud abhängig.

Als Alternative kann ich die Software TASMOTA empfehlen. Man muss zwar einmalig jedes Gerät mit TASMOTA flashen (ein TTL-Konverter mit 3,3V wird benötigt), ist dann jedoch unabhängiger. Man kann Schaltbefehle über ein Webinterface steuern oder das Gerät per MQTT an eine Haussteuerung oä. anbinden. Für diese Variante hat man zwar ein bißerl mehr Aufwand, ist aber unabhängiger.

Details zu TASMOTA und dem Flashen dieser Firmware gibt es hier:
https://github.com/arendst/Sonoff-Tasmota/wiki

Allgemein, App, Smartphone, Unterwegs

Induktives Laden mit Qi

5 Kommentare
Samsung S7 hat induktiv voll geladen

Ich beziehe mich bewusst nicht nur auf Handys bzw. Smartphones, weil ich glaube, dass dieses induktive Laden viele andere Anwendungsmöglichkeiten bietet. Ich möchte ja auch den Akku eines tragbaren LoRaWAN-Sensors künftig induktiv laden, aber das ist ein anderes Thema…

Dass es die Möglichkeit gibt, Smartphones induktiv aufzuladen, ist mir schon länger bewusst. Ich habe aber auch gesehen, dass es mehrere Standards gibt, die nur eingeschränkt (wenn überhaupt) kompatibel erscheinen. Im letzten Urlaub habe ich einiges zu dem Thema gelesen und bin nun auf den Zug aufgesprungen und sehr begeistert.

Hauptgrund war, dass es nun einen von allen Herstellern anerkannten und kompatiblen Standard gibt und meine Bedenken hinsichtlich Gesundheitsproblemen durch permanente Strahlung zerstreut wurden.

Funktionsweise

Induktives Laden läuft: 53%. Ca. 1 h 22 min bis voll geladen

Wie funktioniert das induktive Laden? Im Prinzip werden eine Ladeschale (oder Halterung) benötigt, die mit einer Stromversorgung (meist USB) verbunden ist und ein Endgerät (Smartphone), das induktives Laden unterstützt. Sobald man das Smartphone auf die Ladeschale legt, beginnt das Handy zu laden.

Dabei bedient man sich einer Technologie, die von Transformatoren her längst bekannt und im Einsatz ist: eine Spule in der Ladeschale induziert ein Magnetfeld und dieses wird von einer Spule im Smartphone wieder in elektrischen Strom umgewandelt.

Spezifikation

Das Wort „Qi“ bedeutet auf chinesisch „Lebensenergie“ und ist vielleicht von Qi Gong her bekannt. Hier beschreibt der Name die proprietäre Technologie des Wireless Power Consortiums. Nachdem sich der konkurrierende Standard „Powermat“ der „Power Matters Alliance“ zurückgezogen hat, ist nun Qi der de-facto Industriestandard.

Die Übertragung findet im Bereich der Langwelle von 110 bis 205 kHz mit nominal 19 Volt statt. Es gibt mehrere Leistungsklassen von 5-15 Watt (Low Power) bis 120 Watt (Medium Power). Ich glaube, dass dadurch in naher Zukunft auch Anwendungen für andere Geräte mit höherem Energiebedarf ermöglicht werden. Die Übertragung funktioniert meist bei einem Abstand im Bereich einzelner Millimeter. Die Effizienz der Übertragung liegt je nach Gerät bei 60-90%, ist also immer verlustbehafteter im Vergleich zum Laden über Kabel.

Besonders gut hat mir gefallen, dass der Standard auch eine Datenübertragung zwischen den Geräten definiert. Diese ist mit 2 kbit/s spezifiziert und ermöglicht den Informationsaustausch zwischen den Qi-Komponenten. Damit ist nun auch klar, dass der Sendeteil (zB. die Ladeschale) nicht permanent ein starkes elektromagnetisches Feld erzeugt, sondern erst mit höherer Leistung beginnt, sobald ein kompatibles Endgerät erkannt wurde, die Datenverbindung hergestellt ist und die Geräte vereinbart haben, welche Ladung (zB. Leistung) durchgeführt wird.

Kann mein Smartphone Qi und was mache ich, wenn nicht?

Die einfachste Möglichkeit herauszufinden ob das eigene Smartphone Qi unterstützt ist wie üblich: ausprobieren, oder im Handbuch nachlesen. 😉

Samsung Smartphones sind beispielsweise seit dem Samsung S6 Qi-fähig und Apple-Geräte seit dem iPhone 7.

Es ist aber auch möglich, das eigene Smartphone nachzurüsten. Dazu gibt es recht günstig dünne induktive Ladeempfänger, die man zB. in der Schutzhülle des Handys verstecken kann. Diese Empfänger werden zB. per USB Micro (oder Typ C) an das Smartphone angeschlossen. Das Handy merkt eigentlich nicht, dass es induktiv geladen wird, sondern erkennt natürlich nur, dass es an einem „Ladekabel“ hängt. Der USB-Port ist damit natürlich auch belegt – das sollte man beachten. Die Empfänger sind so dünn und oft so passgenau, dass sie zwar einerseits kaum sichtbar/spürbar sind, andererseits aber kaum Spielraum haben und man immer die Hülle herunternehmen muss, falls man den USB-Port anders nutzen möchte.

Ladeempfänger ist zu lang und verdeckt den Fingerprint Sensor teilweise

Außerdem empfehle ich sehr, nachzusehen ob der Ladeempfänger von der Form für das eigene Smartphone passt. Bei meinem ersten Kauf für mein Nexus 5X habe ich einen zu großen Empfänger gekauft, der verdeckt fast die Hälfte des Fingerprint-Scanners. Den verwende ich nicht, also stört es mich nicht, aber hätte ich besser aufgepasst, hätte ich was Passendes um’s gleiche Geld bekommen.

Ergebnisse im Test

Mittlerweile habe ich ein paar Ladeschalen und ein paar Qi-fähige Endgeräte getestet, sowie eine handvoll Handys nachgerüstet.

Es funktioniert alles einwandfrei. Man muss sich daran gewöhnen, dass die Ladezeiten länger werden, weil die meisten kostengünstigen Qi-Geräte 800mAh oder vielleicht 1000mAh schaffen. Damit brauchen moderne Handyakkus schon rein rechnerisch 4-5 Stunden für eine volle Ladung. Aufgrund des Verlusts in der Übertragung wird das nochmal erheblich mehr. Über Nacht ist das aber normalerweise kein Problem.

Ich erwähne die längere Ladezeit nur deswegen so explizit, weil ich das Gefühl habe, dass bei kabelgebundenen Lademöglichkeiten gerade die Erwartungen sehr hoch gesteckt werden, nämlich „mehrere zig“-Prozent in einzelnen Minuten laden zu können. Dort kommen auch Ströme von 4,6 Ampere zum Einsatz, die über den USB-Port in den Akku „gedrückt“ werden. (Vgl. Qualcomm Quick Charge 3 oder 4+).

Eine berichtenswerte Erfahrung habe ich aber auch gemacht: ich habe mir eine Ladeschale ins Büro gelegt. Tagsüber bin ich öfters in Besprechungen und dann meist nur 20 Minuten kurz am Platz die neuen Emails durchschauen. Früher habe ich dabei nie oder selten das Handy angesteckt und aufgeladen. Heute lege ich es regelmäßig bei diesen kurzen Aufenthalten auf die Ladeschale. Und das führt dazu, dass ich tagsüber immer wieder nachlade und so an manchen Tagen eigentlich kaum noch unter 90% auf der Akkuanzeige komme…

Eine weitere Erkenntnis ist, dass man manche Smartphones relativ genau platzieren muss, damit das Laden funktioniert. Die Spulen müssen möglichst übereinander liegen. Ein Samsung S6 zum Beispiel funktioniert auf einem meiner getesteten Ladeschalen (es handelt sich um dieses Modell) nur, wenn ich es eher rechts platziere. Mittig funktioniert es nicht und links auch nicht. Andere Smartphones funktionieren mittig und rechts, aber links auch nicht. Daran habe ich mich aber recht schnell gewöhnt und lege die jeweiligen Geräte mittlerweile ohne viel Nachdenken richtig auf.

Folgende Geräte sind auf den Fotos in diesem Blog gezeigt:

Fazit

Ich liebe es! Einziger Wermutstropfen ist der Energieverlust bei der Übertragung. Das ist sehr schade und Verschwendung. Von der Zuverlässigkeit, Kompatibilität und Geschwindigkeit (für mich ausreichend) alles super!

Meldung eines Samsung S7
Amateurfunk, App, APRS, Arduino, Code, Linux, LoRa, Smartphone, Unterwegs

LoRa Reichweite mit TTNmapper abschätzen

17 Kommentare

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:

Amateurfunk, App, Arduino, Code, Linux, LoRa, Raspberry Pi, Unterwegs

LoRa Sensor mittels Arduino und LoRa Shield

16 Kommentare

Ü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;
Amateurfunk, App, Code, Funkfeuer, IPv6, Linux, Raspberry Pi, WLAN

Speedtest über Ubiquiti Edgerouter CLI

Ein Kommentar

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

App, Firewall, Smartphone, Unterwegs, WLAN

WLAN Hotspots: automatisch mittels App einloggen

3 Kommentare

Ich habe diese App seit Monaten gesucht! Für mein Privathandy habe ich nämlich einen Wertkartenvertrag ohne mobile Datennutzung. Damit bin ich nicht nur im Ausland auf Hotspots angewiesen.

WIFin heißt das Ding. Es ist gratis und hier im Google Play Store zu finden.

Update 3.9.2016: die App heißt nun Neer WiFi, ist aber weiterhin unter dem oben genannten Link zu erhalten.

Screenshot_20160829-174937Screenshot_20160829-174946Die App erkennt WLANs, bei denen vor Akivierung des Internetzugangs noch Nutzungsbedingungen akzeptiert werden müssen. Gängige Captive Portal-Lösungen erkennt die App automatisch und versucht sie freizuschalten – aber erst sobald man das möchte. In Zukunft führt die App die nötigen Schritte dann von selbst für die der App bekannten SSIDs aus.

Es ist schon super, wenn man mit der Schnellbahn fährt und alle 2-3 Stationen synct das Handy mit dem Gratis WLAN am Bahnsteig… Das Ganze funktioniert so flott, dass man quasi mit dem Einfahren in die Station auch schon surfen könnte.

Konfigurieren eines Hotspots

Wenn ein WLAN genutzt wird, das die App noch nicht kennt, zeigt sie dies an.

Screenshot_20160829-174959Indem man auf diese Meldung tippt wird für das aktuelle WLAN eine Konfiguration angelegt. Im ersten Feld fragt die App, ob eine spezielle URL aufgerufen werden soll. Im Zweifelsfall drückt man einfach auf „continue“ und lässt das Feld leer.

Screenshot_20160829-175004Die App analysiert nun im Hintergrund die „Landing Page“, wie die Seite auch genannt wird, auf denen die Nutzungsbedingungen präsentiert werden. Meist ist diese Seite mit einem Button zu bestätigen und manchmal ist auch ein Hakerl zu setzen, um seine Zustimmung zu den Bedingungen zu bestätigen. Die App führt ggf. beide Aktionen aus bestätigt dies mit einer Meldung: „We’re done doing the Math, the rest is history!“. Mit dieser Siegesmeldung bestätigt die App, dass der Internetzugang freigeschaltet ist.

Screenshot_20160829-175018In Zukunft erscheint eine Meldung sobald man sich wieder mit dem WLAN verbindet. Unmittelbar darauf bestätigt die App selbstständig die Nutzungsbedingungen und man ist online.

Im Hauptmenü kann man die SSIDs, zu denen es Konfigurationen gibt, anzeigen und ggf. die Profile/Konfigurationen wieder löschen.

Eine Status-Seite gibt Auskunft zu grundlegenden Parametern der Internet-Verbindung.

Beta Programm

Es gibt ein Beta-Programm, zu dem man sich über’s entsprechende Menü anmelden kann. In der Beta-App habe ich bisher keine Unterschiede festgestellt.

Gleiche SSID aber anderes Captive Portal schlägt fehl

Es gibt Hotspot-Anbieter, die auf verschiedenen Standorten unterschiedliche Captive Portal-Produkte einsetzen, die mit unterschiedlicher Methode funktionieren. Damit hat die App Probleme. Sie erlernt die Methode, die bei der ersten Verbindung erkannt wurde, und versucht auf diesem Weg bei allen gleichnamigen zukünftigen Hotspots vorzugehen. An Standorten, die ein bißerl anders funktionieren, ist sie manchmal erfolglos.

Rechtlicher Gedanke

Die Nutzungsbedingungen haben einen Zweck: der Benutzer soll informiert werden und aufgefordert worden, nichts Unrechtes über dieses Netzwerk zu tätigen; gleichzeitig hält sich der Betreiber in mehrfacher Hinsicht schadlos. Durch das automatisierte Akzeptieren der Nutzungsbedingungen hat man diesen Bedingungen vielleicht nicht rechtsgültig zugestimmt? Selbst wenn man beim ersten „Anlernen“ der Landing Page in der App die Bedingungen gelesen hat, wird man Änderungen ebendieser vermutlich nicht erkennen können. Ich empfehle also, an Standorten, die man besucht, immer wieder bewusst die Nutzungsbedingungen zu reviewen. Welche SSIDs das sind, zeigt die App ja an…

Allgemein, App, Funkfeuer, Smartphone, Unterwegs, WLAN

Sichere SMS?

3 Kommentare

Ich werde oft gefragt, ob ich WhatsApp verwende. Das tu ich nicht, vor allem aus der Überlegung, dass WhatsApp ursprünglich keine zuverlässige Verschlüsselung bzw. Sicherheit geboten hat.

Mittlerweile hat sich die Situation geändert: WhatsApp wurde von Facebook übernommen und WhatsApp bietet nun Verschlüsselung an. Ein Umstieg ist für mich trotzdem kein Thema.

Bitte beachtet, dass ich in diesem Artikel meine persönliche Wahl beschreibe, die ich gerne als Empfehlung weitergebe. Ich habe damit schließlich gute Erfahrungen gemacht. Es gibt in diesem Themenkreis  auch andere Produkte und Lösungen, die eine Berechtigung haben. Ich möchte mit diesem Artikel keine Übersicht über die verfügbaren Lösungen schaffen, sondern meine konkrete Auswahl erklären und begründen.

Was sind also die Alternativen, für die ich mich entschieden habe?

Ich sehe zwei Lösungen die ich hier im Dunstkreis von Instant Messaging, SMS & text messages, Austausch von Video-, Foto-, Dokument-, Standortinformationen oder Kontaktdaten erwähnen würde.

Threema

Als viele User begonnen haben WhatsApp zu nutzen, war mir – wie oben erwähnt – die Verschlüsselung zu unsicher oder hat überhaupt gefehlt, wodurch ich auf Threema als Alternative aufmerksam wurde.

Threema umfasst die für mich wichtigen Funktionen und Eigenschaften. Es wurde einem Schweizer Unternehmen geschaffen, das von Anfang an auf Ende-zu-Ende-Verschlüsselung nach Industriestandards Wert gelegt hat. Eine genaue Beschreibung der Vorteile findet man naturgemäß auf der Webseite von Threema: https://threema.ch/de/

Signal / SecureText

SecureText konkurriert nicht automatisch mit WhatsApp oder Threema. Es ist eigentlich ein Ersatz für die SMS App am lokalen Smartphone. Eingehende SMS-Nachrichten können – entsprechende Konfiguration vorausgesetzt – von SecureText empfangen werden. Sie werden auch über SecureText beantwortet.

Der Clou dabei: wenn der/die Empfänger/in einer SMS auch SecureText installiert hat (das erkennt SecureText automatisch an der Handynummer), wird die Nachricht stark verschlüsselt über das Internet versendet und nicht als SMS. SecureText zeigt das über ein Symbol an (ein verschlossenes Schloss beim Sendeknopf weist auf eine sichere Übertragung über das Internet hin).

Was mir an SecureText gut gefällt ist, dass es ein schöner Ersatz für die Standard-SMS-App ist, keinen Zusatzaufwand produziert und dennoch

  1. Kosten spart (keine SMS-Kosten, wenn nicht nötig, sondern Versand über’s Internet – auch im Ausland interessant)
  2. im Hintergrund automatisch verschlüsselt – wenn es der/die Empfänger/in unterstützt.

SecureText wurde mittlerweile zu „Signal“ umbenannt und ist unter diesem Namen in den App Stores kostenfrei zu finden.

Gibt es auch Nachteile?

Durchaus. Wobei das teilweise auch auf WhatsApp und andere zutrifft.

Kosten

Es wurde schon oft diskutiert: sichere Apps dürfen etwas kosten. Oder umgekehrt gedacht: woran verdienen die Unternehmen, die kostenlose Apps verteilen? Da liegt immer der Verdacht nahe, dass es die Inhalte der User sind, die den Wert darstellen und kommerziell genutzt werden.

Diejenigen, die wirklich so leiwand sind, dass sie gute Produkte kostenfrei zur Verfügung stellen, sind meistens auch so leiwand, dass sie den Source Code zur Verfügung stellen. Und das hat wirklich einen Mehrwert, weil man dann die Sicherheit nachvollziehen kann.

Threema kostet aktuell CHF 2,00 (oder 0,0048 BTC, BitCoins)  auf der Homepage oder € 2,49 im Google Play Store. Bei iOS löhnt man € 2,99 im Apple App Store.

SecureText (heißt jetzt: Signal) ist kostenlos erhältlich.

Proprietär

WhatsApp-Benutzer können nur mit WhatsApp-Benutzern Nachrichten austauschen. Threema-Benutzer können nur mit Threema-Benutzern Nachrichten austauschen. Das ist weitreichend durch die Technologie vorgegeben.

Es zahlt sich also aus, mal im Freundeskreis zu fragen, welche Apps genutzt werden und ob eine Änderung zu Threema denkbar wäre. Die Antwort muss man dann mit den eigenen Sicherheitsbedenken abzuwägen.

Im Zweifelsfall kann man ja mehrere Messaging Apps installieren. Das ist aber nicht mein Weg.

kein Internet = keine Nachrichten

Das ist mir im Fall von Threema unangenehm aufgefallen. Da kann aber Threema eigentlich nichts dafür. Aus Sicht der Nutzbarkeit möchte ich trotzdem darauf hinweisen:

  1. Mein Handy (eigentlich: Smartphone) ist oft tagelang über das Firmen-VPN verbunden. Aus dem Firmen-VPN kann aber leider weder Threema noch SecureText verschlüsselte Nachrichten ins Internet senden oder von dort empfangen. Die Sicherheitssysteme des Unternehmens unterbinden das.
    Die Nachrichten „hängen“ also lange in meinem Handy rum, bis ich irgendwann zB. bei einem öffentlichen Hotspot mit direktem (ungefilterten) Internetzugang befinde. Und dann geht’s rund: plötzlich kommen zahlreiche Nachrichten  aus den letzten Stunden an und meine Nachrichten gehen erst jetzt raus.
    Wenn jemand mit dem Smartphone eh immer oder zumindest regelmäßig direkt mit dem Internet verbunden ist, hat er/sie das Problem aber wahrscheinlich nicht.
  2. Ich bin ja recht engagiert bei Internetprojekten tätig. Oft geht es darum, einen Internetzugang herzustellen (= den gibt es also noch nicht). Und wenn da ein Kollege am Dach ein Problem per Threema beschreibt, kann es sein, dass ich die Nachricht erst erhalte, sobald das Problem behoben ist und die Internetverbindung für uns beide wieder klappt. Das ist zwar auch eine Erkenntnis, war aber nicht hilfreich.
    In solchen Fällen ist eine klassische SMS immer noch gut. Man kann im SecureText das auch einstellen, dass man nun lieber eine SMS versenden möchte, als eine verschlüsselte Nachricht – auch wenn der/die Empfänger/in damit umgehen könnte.
  3. mir fallen da noch mehrere Beispiele ein: im fernen Ausland nutzt man üblicherweise keine permanente mobile Datenverbindung. Entsprechend kommen also auch dort die Nachrichten nicht sofort durch. SMS würden sofort ankommen und der Empfang auch keine – oder geringe? – Kosten verursachen.

Fazit: kein internet = keine Nachrichten. Das sollte einem bewusst sein.

Nachtrag / Update

Ich wurde von mehreren Seiten auf diesen Blogbeitrag angesprochen. Der wesentliche Input war, dass WhatsApp mittlerweile die Verschlüsselung von Signal übernommen hat. Im Gegenzug hat Google eine Alternative („Allo“) gelauncht, die zweifelhafter Weise nur bei Nutzung des Inkognito-Modus verschlüsselt.

2. Nachtrag (August 2016)

Mittlerweile hat Whatsapp angekündigt, weitere Nutzungsdaten und auch die Telefonnummern der User an Facebook weiterzureichen, um damit genauere Profile zu ermöglichen. Widerstand scheint zwecklos, es gibt jedoch die Möglichkeit, die Reichweite der Nutzung dieser Daten einzuschränken – ganz lässt sich die Weitergabe nicht verhindern.

Ich freue mich, dass seit der Ankündigung von WhatsApp/Facebook viele meiner Kommunikationspartner und Freunde zu den in diesem Beitrage beschriebenen Systemen gewechselt sind, die ich auch nutze.

App, Code, Firewall, Funkfeuer, Linux

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

2 Kommentare

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.

Allgemein, App, Smartphone, Unifi, WLAN

Unifi AP-AC-Pro: erste Eindrücke

5 Kommentare

Heute habe ich meinen ersten Unifi AP AC Pro erhalten. Eigentlich hat der Händler die Geräte – nach eigenen Angaben – erst ab Jänner 2016 lieferbar, aber ein einzelnes Gerät konnte er mir reservieren und schicken.

Update Dezember 2016: mittlerweile gibt es modernere Access Points, als ich in diesem Beitrag beschreibe. Ich habe dazu einen anderen Blogbeitrag verfasst und würde empfehlen, eher ein Produkt der moderneren UAP AC-Serie zu wählen, falls dieser Artikel zu einer Kaufentscheidung herangezogen wird.

Nachtrag Jänner 2017: mittlerweile sind auch 802.11ac-fähgie Geräte im leistbaren Segment für Außeninstallationen erschienen, die ich in einem separaten Artikel vorstelle. Diese Geräte eigenen sich auch gut für den Innenbereich.

Optik und Montage

Optisch sieht das Gerät den anderen (runden) Unifi APs sehr ähnlich, als Unterschied fällt mir eigentlich nur das neue Ubiquti-Logo auf. Ich möchte einen Unifi AP LR ersetzen, die Montagehalterung ist die gleiche bzw. passt und so musste ich nur den alten von der Halterung herunterdrehen und den neuen AP reindrehen. Das klingt ein bißerl einfacher, als es tatsächlich ist: die Öffnung für den Schraubenzieher, mit dem der AP gehalten wird, hat mich ganz schön ins Schwitzen gebracht, aber es war zu schaffen.

Inbetriebnahme

Das Gerät hat sich sofort an meinem lokalen Unifi Controller angemeldet und problemlos adoptieren lassen und ich habe das WLAN-Profil für zu Hause ausgewählt.

Ich verwende die aktuelle Version 4.7.5 des Controllers. Der AP wurde mit SW Version 3.4.7.3231, die mit einem Klick auf „Upgrade“ rasch auf 3.4.7.3284 gehoben war.

Und schon haben sich die ersten Geräte über den neuen AP verbunden.

Neu: Konfiguration per Handy App

Ich habe es nicht selbst probiert, aber die neue Generation von Unifi APs können per Smartphone-App (derzeit nur Android App) konfiguriert werden und benötigen somit keinen Unifi-Controller bei der Inbetriebnahme!

erste Tests

windowsacViele Geräte verbinden sich lieber über 2,4 GHz und 802.11n-Standard. Nur einzelne Laptops und Smartphones nutzen den 802.11ac-Standard auf 5 GHz. Sie zeigen aber Übertragungsraten von mehr als 300 MBit/s an (im Bild sind es 780 MBit/s, also 2×2 MIMO mit 802.11ac bei 80 MHz Kanalbreite – das Maximum wäre 867 MBit/s). Meine Tests haben derzeit keine gesteigerte Bandbreite ergeben, aber ich möchte das in den nächsten Tagen noch genauer testen.

Was mir auffällt

Ein paar neue Features sieht man sofort im Unifi Controller:

  • unifi-rf-environmentRF environment

Damit scannt der Access Point die Umgebung (alle Clients verlieren derweil die Verbindung, es wird jedoch mit einer kurzen Warnung darauf hingewiesen) und zeigt die Belegung der Kanäle und deren Rauschen (Interference) an. Das finde ich sehr interessant, weil man so auch aus der Ferne einen möglichst idealen Kanal finden und konfigurieren kann.

  • unifi-5ghz-kanäle-acKanalauswahl

Bei 2,4 GHz bietet der AP die üblichen 13 WLAN Kanäle an.
Bei 5 GHz kann man jedoch nur aus Kanal 36, 40, 44 und 48 wählen. Der Grund liegt wohl darin, dass bei diesen Indoor-Kanälen kein DFS gefordert ist bzw. offenbar die APs derzeit DFS nicht unterstützen. Aufgrund meiner Ländereinstellung „Austria“ werden somit die anderen Kanäle ausgeblendet.

  • unifi-rf-env5ghzKanalbandbreite

Standardmäßig werden 40 MHz Kanalbandbreite genutzt. Man kann diese Einstellung auf 20 MHz reduzieren oder auf 80 MHz erweitern. Die Top-Geschwindigkeiten sind natürlich nur mit 80 MHz zu erzielen. Nachdem nur 4 Kanäle zur Verfügung stehen, kommt es hier leider zu Überschneidungen, sobald man 40 oder 80 MHz Kanalbandbreite einstellt.

Fazit

Das Gerät war superschnell installiert und in Betrieb genommen – vor allem, da ich es ja in meine bestehende Unifi-Umgebung integriert habe. Ich würde mir noch DFS-Unterstützung wünschen, damit auch alle, oder zumindest mehr als 4 Kanäle, zur Verfügung stehen.