Schlagwort-Archive: App

WLAN Hotspots: automatisch mittels App einloggen

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…

APRS Smartbeaconing bewährt sich bei mir nicht

AP510 mit SmartBeaconing, zu Fuß + mit Straßenbahn unterwegs
AP510 mit SmartBeaconing, zu Fuß + mit Straßenbahn unterwegs

SmartBeaconing ist eine gute Idee: statt per APRS seine Position alle x Sekunden auszusenden und damit das APRS-Netz unnötig zu belasten, wird die Position nur gesendet, sobald es das System „smart“ findet: bei Richtungsänderungen, wesentlichen Geschwindigkeitsänderungen, etc.

Das entlastet das Netz hinsichtlich der Anzahl an Meldungen, die direkt oder über Digipeating übertragen werden und erhöht die Wahrscheinlichkeit für andere Benutzer, dass Airtime für deren Aussendung frei ist.

AP510 im Rucksack in der Straßenbahn (Antenne ist hier testweise eine Nagoya NA-771)
AP510 im Rucksack in der Straßenbahn (Antenne ist hier testweise eine Nagoya NA-771)

Ich habe überall SmartBeaconing verwendet. Schließlich bin ich großteils im Stadtgebiet von Wien und in der näheren Umgebung unterwegs und dort ist die Dichte an APRS-Empfängern & -Digipeatern sehr hoch.

AP510 APRS Tracker am Boot auf der Adria bei Kroatien im Juni 2015
AP510 APRS Tracker am Boot auf der Adria bei Kroatien im Juni 2015

Leider hat sich SmartBeaconing für mich nicht bewährt: obwohl ich mit 5 Watt über eine externe Magnetfußantenne (Nagoya UT-106UV) vom Autodach aus sende, werden nur 30-40% meiner Meldungen aufgenommen. Und das reicht nicht, um die Strecke annähernd korrekt abzubilden. Vor allem, wenn eine Richtungsänderung nur alle 1-2 Minuten passiert, hinterlasse ich nur alle 5 Minuten einen Punkt auf der Map bei dieser schlechten Erfolgsquote der Übertragung.

Ich habe daher SmartBeaconing deaktiviert und sende im Moment stur alle 30 Sekunden. Damit bekomme ich ausreichend Übertragungen zusammen, um die Route gut abzubilden. Gleichzeitig ist mir bewusst, dass dadurch das Netz stärker belastet wird. Da ich aber nicht viel mit dem Auto unterwegs bin, denke ich, dass es zumutbar ist

APRS Strecke mit Argent OpenTracker USB ohne SmartBeaconing
APRS Strecke mit Argent OpenTracker USB ohne SmartBeaconin

 

Unifi Controller in fhem einbinden

Ich habe bereits über meine Unifi-Installation geschrieben, die sich weiterhin bewährt.

Mit großer Freude habe ich gelesen, dass seit 23. August 2015 auch ein Unifi-Modul für fhem verfügbar ist! (Das Changelog sagt: „added: 74_Unifi.pm for the Ubiquiti Networks (UBNT) – Unifi Controller“)

Das muss ich gleich probieren! Einen Unifi-Controller habe ich laufen, jetzt möchte ich diesen mit fhem verbinden und anhand der Clients im WLAN die Anwesenheitserkennung von fhem nutzen.

Mittlerweile habe ich den Unifi Controller in Version 4.6.6 bei mir laufen. Von Version 3 zu Version 4 hat sich einiges geändert, auch in der Unifi API. Es ist daher verständlich, dass man die Versionnummer angeben muss. Gleichzeitig ist es toll, dass das fhem-Modul sowohl Version 3 als auch Version 4 unterstützt.

Ich habe für den Unifi-Zugriff aus fhem einen eigenen User „fhem“ mit „Read Only“-Berechtigung im Unifi Controller angelegt.

Der Zugriff von fhem war mit einer Zeile erledigt:

define myunifi Unifi 192.168.1.9 443 fhem geheim 30 default 4

Der Syntax lautet gemäß Perl Modul:

define <name> Unifi <ip> <port> <username> <password> [<interval> [<siteID> [<version>]]]

In der Commandref stehen auch die Details zur Nutzung des Moduls.

Die Standardwerte dafür sind:

  • interval = 30 Sekunden
  • siteID = default
  • version = 4

Ich habe dennoch alles explizit angegeben. Damit hoffe ich, dass in zukünftigen Versionen keine Problem auftauchen (zB. sobald es Version 5 gibt, etc.).

fhemunifi-siteidZuerst habe ich den angezeigten Namen vom Unifi-Controller meiner Site als siteID anzugeben. Damit habe ich  keine Werte bekommen. Nach kurzer Suche habe ich die Fehlermeldung im Log gefunden:

myunifi (Unifi_GetClients_Receive) - Failed! - state:'error' - msg:'api.err.NoSiteContext' - This error indicates that the <siteID> in your definition is wrong. Try to modify your definition with <sideID> = default.

Folgender Hinweis hilft: in der URL des Controller sieht man, mit welcher siteID man verbunden ist, auch wenn diese einen anderen Namen trägt, der im Controller angezeigt wird:

Es hat dann sofort funktioniert: im „Unsorted“-Bereich habe ich nun das Objekt myunifi und alle verbundenen Endgeräte:fhemunifi1Die Daten, die fhem vom Unifi Controller bezieht sind umfangreich und ermöglichen viele Anwendungen, auch außerhalb der Presence-Funktion. Hier die Details zu einem Client:unifi2

====================================== 
_id = 558XXXXXXXXXXXXXb85ae047 
_is_guest_by_uap = false 
_last_seen_by_uap = 1441082804 
_uptime_by_uap = 33149 
ap_mac = 24:a4:XX:XX:XX:c3 
assoc_time = 1441043174 
authorized = true 
bssid = 2e:a4:XX:XX:XX:c3 
bytes-r = 3 
ccq = 991 
channel = 7 
essid = MeineSSID 
first_seen = 1435052270 
hostname = android-bfeXXXXXXXXX9f0f 
idletime = 24 
ip = 192.168.XXX.103 
is_guest = false 
is_wired = false 
last_seen = 1441082804 
latest_assoc_time = 1441049655 
mac = 60:af:XX:XX:XX:e5 
name = Stefan Samsung XXXX
noise = -94 
note = 
noted = false 
oui = SamsungE 
powersave_enabled = true 
qos_policy_applied = true 
radio = ng 
radio_proto = ng 
roam_count = 2 
rssi = 40 
rx_bytes = 1339759 
rx_bytes-r = 3 
rx_packets = 6309 
rx_rate = 6000 
signal = -54 
site_id = 53ecXXXXXXXXXXXXXXX91e2a 
tx_bytes = 1905377 
tx_bytes-r = 0 
tx_packets = 5576 
tx_power = 30 
tx_rate = 72222 
uptime = 39630 
user_id = 55892XXXXXXXXXXXXX5ae047 
usergroup_id = 
======================================

neue & weitere Funktionen

Das Modul für Unifi ist neu im fhem. Es wird laufend weiterentwickelt, so wurde letzte Nacht wieder um Funktionen erweitert, zB:

  • einen Client disconnecten,
  • einen Access Point restarten
  • die „Locate“-Funktion eines APs ein- & ausschalten (blinken)
  • Alarme am Controller archivieren

Am besten behält man das fhem Changelog im Auge. Dort werden Änderungen & Erweiterungen protokolliert.

Erfahrungsbericht Ubiquiti Unifi

Unsere Wohnung ist ja gar nicht so groß. Aber da wir zwei Wohnungen verbunden haben, ist der Wohnbereich so großzügig verteilt, dass ein Access Point nicht zuverlässig alle Zimmer versorgen kann.

Ich habe also am Anfang einen zweiten Access Point aufgestellt und gehofft, dass ich es in der ganzen Wohnung ins Internet schaffe. Das hat auch soweit funktioniert. Leider fangen die Probleme an, wenn man sich in der Wohnung bewegt und den Bereich des derzeit aktiven APs verlässt. WLAN hat nämlich die Eigenschaft, dass es so lange eine Verbindung zum bestehenden AP hält, bis diese wirklich unbrauchbar wird. Erst dann ermitteln die Endgeräte den stärksten AP neu und verbinden sich dorthin. Auch bei gleicher SSID hat der Übergang nicht besser funktioniert.

Damit klappt zwar üblicherweise das Surfen im Internet, aber ein VoIP-Call bricht beim Herumwandern in der Wohnung ab.

Controller

Aus dem Firmenumfeld kenne ich WLAN-Lösungen, die zentrale Server (= Controller) einsetzen, um alle Access Points inkl. der verbundenen Clients zu verwalten und die Verbindung von Netzwerkseite her optimieren, wenn ein Client einen besseren Access Point nutzen sollte.


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.


Bei der Suche nach einer Lösung für meine Wohnung bin ich auf die Unifi-Produktreihe von Ubiquiti gestoßen. Ubiquiti ist mir als günstiger aber zuverlässiger Hersteller bereits aus meinen HAMnet– und Funkfeuer-Erlebnissen bekannt und meine bewährten Händler haben die Geräte zu guten Konditionen lieferbar.

Im Folgenden beschreibe ich das endgültige Setup, das sich eigentlich erst Schritt für Schritt (Gerät für Gerät) entwickelt hat.

Zero Handoff & Unifi Controller

Bei Unifi hat mich besonders die Zero-Handoff Funktion interessiert. Damit verspricht Unifi die oben beschriebene Funktionalität, die ich von Controllern kenne, auch ohne zentralen Controller! Klingt nach Zauberei, ist aber dadurch zu erklären, dass die Access Points permanent miteinander in Kontakt stehen und so jeweils eine aktuelle Sicht auf die gesamte WLAN-Umgebung und die verbundenen Geräte haben. Ein zentraler Controller ist somit nicht notwendig. Natürlich ist die Voraussetzung, dass die Access Points im selben Netzwerksegment platziert werden.

Das heißt: zum Einrichten der Lösung, muss man die Software vom zentralen Controller schon einmalig installieren (zB. am Laptop). Die SW ist für Linux (zB. auch als .deb-Paket), Windows und Apple-Produkte frei zum Download verfügbar: https://www.ubnt.com/download/.

Für den Betrieb der Lösung ist der Controller nicht erforderlich, außer man möchte etwas Ändern/Umkonfigurieren oder Statistiken sammeln (zum dauerhaften Sammeln muss der Controller auch permanent laufen).

Ich habe den Controller auf einer dedizierten Virtuellen Maschine auf meinem VMWare ESXi unter Ubuntu Linux LTS dauerhaft in Betrieb. Beim Einbinden der Paketquellen in Ubuntu gibt es drei Möglichkeiten:

  • stable: am weitesten verbreitet, nur stabile und bewährte Software- & Firmwarestände. Sicher die richtige Wahl für den produktiven Einsatz.
  • rapid: Software, die sich bereits länger als Beta bewährt hat, sich aber noch nicht für „stable“ eignet. Hier hat man einen guten Kompromiss zwischen neuen Funktionen und stabiler Software.
  • beta: Testversionen

Ich habe mich für „apt-get install unifi-rapid“-Variante entschieden und damit gute Erfahrungen gemacht.

Access Points

UAP LR an der Decke montiert
UAP LR an der Decke montiert

Nachdem ich eine preiswerte Lösung für die Wohnung gesucht habe, habe ich mich für die UAPs entschieden, die nur im 2,4 GHz-Bereich arbeiten. Das ist aus Performancesicht natürlich nicht ideal, weil der ganze 5 GHz-Bereich nicht abgedeckt ist, aber für uns vollkommen ausreichend, auch weil die nächstgrößere Variante mindestens das dreifache gekostet hätte.

Ich habe also folgende Geräte gekauft:

UAP einfach oben auf's Kastl gelegt
UAP einfach oben auf’s Kastl gelegt

Der UAP Access Point hat etwas mehr als € 50,- gekostet. Der LR schon 30% mehr. Das war übrigens keine gute Investition: gemäß regulatorischer Auflagen darf das WLAN-Equipment maximal 100 Milliwatt (mW) EIRP aussenden, das sind bekanntlich 20 dbm. Der UAP schafft max. 20 dbm und der UAP LR schafft 28 dbm. Das dürfte auch der wesentliche Unterschied für die „Long Range“-Angabe sein. Wenn man nun dem Controller mitteilt, dass sich diese Installation in Österreich befindet, lassen sich alle Geräte mit maximal 20 dbm konfigurieren. Das LR-Feature fällt somit flach. Daher: lieber einen UAP mehr kaufen als UAP LRs, bei denen man die Leistung sowieso nicht nutzen sollte.

Ubiquiti PicoStation zur Versorgung des Gartens
Ubiquiti PicoStation zur Versorgung des Gartens

Die PicoStation habe ich im Fenstersims außen montiert und funktioniert im ganzen Garten wunderbar. Leider haben meine Fenster eine Dämpfung von 15-20 db, wodurch das Gerät nur schlecht in der Wohnung erreichbar ist. Aber für indoor habe ich ja die UAPs.

Die Access Points kann man übrigens gar nicht direkt konfigurieren. Sobald man den Controller installiert hat, loggt man im Portal das erste Mal ein und findet im Menüpunkt „Access Points“ die Geräte, die der Controller über Broadcast/Multicast im lokalen Netzwerksegment gefunden hat. Diese kann man nun „adoptieren“, wie es bei Ubiquiti heißt.  Bei Bedarf werden die Access Points im Hintergrund automatisch auf die aktuelle Firmware aktualisiert. Die Firmware kommt übrigens mit der Controller-Software mit. Wenn man ein Update installiert, wird bei Bedarf auch automatisch angeboten, die Access Points zu aktualisieren.

Die PicoStation ist hier eine Ausnahme, weil sie eigentlich kein Unifi-Produkt ist, sondern aus der Ubiquiti-AirMax-Reihe stammt. Mit einem einfachen Update wird aus dem Gerät allerdings ein Unifi-Device, das dann vom Controller erkannt, eingebunden und künftig mit Updates versorgt wird.

Konfiguration

Im nächsten Schritt konfiguriert man ein Profil mit den gewünschten WLAN-Netzen (SSIDs) und weist das Profil dann einem oder mehreren Access Points zu. Bis zu 4 SSIDs kann ein Access Point bedienen.

Map in Unifi Controller mit den Access Points
Map in Unifi Controller mit den Access Points

Ich verwende zu Hause drei Netze, die über VLANs getrennt sind. Alle Access Points hängen an einem TPLink TL-SG3424. Mein internes Netz wird nativ an die Access Points übergeben. Das würde ich auch so empfehlen, damit das automatische Erkennen über den Controller funktioniert. Meine zwei anderen Netze werden als VLAN getaggt übergeben. Die Konfiguration ist somit:

  1. VLAN native mit meiner internen SSID und WPA2 zur Kommunikation mit meinem LAN und dem Internet,
  2. VLAN 44 als SSID „hamnet“ mit WPA2, per VLAN vom Internet getrennt, und
  3. VLAN 2 als SSID „guest“ als Gästenetz für direkten Internetzugang.

Ein Gästenetz zu haben ist mir sehr angenehm, weil in meinem internen Netzwerk mittlerweile so viele Dienste über DLNA (zum Sharen von Urlaubsfotos zu den Fernsehern, etc.) laufen und ich nicht will, dass jeder Besucher unkontrolliert in unseren Urlaubserinnerungen blättern kann. Über das Gästenetz wird einfach nur ein guter Internetzugang zur Verfügung gestellt. Außerdem verwende ich es als Testnetz, zB. wenn’s darum geht IPv6 im LAN zu aktivieren. Solche Funktionen bekommt als erstes das Gästenetz…

Für HAMnet ist es auch fein, eine eigene SSID zu nutzen. Ich bin da schon auf einige Probleme draufgekommen, die andere vielleicht nicht bemerken: die meisten Benutzer verbinden das HAMnet mit ihrem internen Router. Dadurch kann man sowohl ins HAMnet als auch ins Internet, ohne neu verbinden zu müssen. Dadurch funktioniert aber auch zB. die DNS-Auflösung über’s Internet, während man im HAMnet ist. In diesem Zusammenhang ist mir schon öfters aufgefallen, dass einzelne Seiten im HAMnet nicht ordentlich funktionieren oder Darstellungsprobleme haben, weil sie Teile des Contents aus dem Internet laden. Wenn man sich also nur im HAMnet, ohne Internetzugang bewegt, ist man meiner Ansicht nach erst wirklich sauber im HAMnet unterwegs.

Liste der aktuell verbundenen Benutzer im Unifi Controller
Liste der aktuell verbundenen Benutzer im Unifi Controller

Ich habe also das Profil mit den drei SSIDs, die jeweils auf VLANs abgebildet werden, per Software mit den Access Points verknüpft und 2 Minuten später waren die SSIDs verfügbar und die ersten Geräte haben sich verbunden! Voila! Fertig!

Kurz zwei Nachteile zu Zero-Handoff

Die Lösung funktioniert wunderbar und ich bin sehr glücklich, viele Vorteile einer controllerbasierten Lösung, vor allem Zero-Handoff, um wenig Geld auch zu Hause nutzen zu können. Zwei Nachteile möchte ich anmerken. Das sind keine groben Probleme, aber ich möchte es erwähnen:

  1. bei jeder Konfigurationsänderung ist immer der gesamte WLAN-Verbund (alle Access Points mit allen SSIDs) für 2-3 Minuten offline und die Endgeräte werden getrennt. Das ist notwendig, da ja ohne Controller alle Access Points ihre Konfigurationen und Stati gegenseitig austauschen müssen, bevor sie einen Zero-Handoff-Dienst anbieten können.
  2. nachdem das Zero-Handoff-Feature auf der Netzwerkseite passiert und das Endgerät gar nicht mitbekommt, dass es von einem Access Point zu einem anderen roamt, müssen alle APs den gleichen WLAN-Kanal nutzen. Damit ist natürlich ein Aufteilen auf mehrere Kanäle, wie es üblicherweise gemacht wird, nicht möglich. Das kann sich negativ auf den Datendurchsatz bzw. die Airtime auf diesem Kanal auswirken.