Schlagwort-Archive: Hotspot

Unifi AP AC Mesh Erfahrungsbericht

An den vielen anderen Beiträgen zum Thema Ubiquiti Unifi könnt ihr erkennen, dass ich diesem System bereits an mehreren Standorten vertraue. Bisher hat sich die Wahl für Unifi für mich bewährt: das System ist einfach zu bedienen, stabil im Betrieb und bietet alle Features, die ich benötige. Vor kurzem (Dezember 2016) sind neue Produkte von Ubiquiti erschienen, die auch im Freien die aktuellen WLAN-Standards kostengünstig bieten.

Das bisherige Dilemma im Outdoor-Bereich

UAP AC Mesh passt dank mitgeliefertem Adapter problemlos in die vorhandene Wandhalterung

Für den Innenbereich habe ich bereits in anderen Beiträgen entsprechende Produkt vorgestellt. Allerdings gab es bisher keine sinnvoll erschwinglichen Outdoor Access Points, die auch 5 GHz mit 802.11ac abdecken. Das war bislang ein großes Manko. Entweder man nimmt den

Unifi Mesh

Zum Glück gibt es nun zwei neue Produkte, die diese Lücke schließen:

Beide sind für den Außeneinsatz gerüstet, unterstützen 2,4 GHz und 5 GHz inklusive 802.11ac und DFS. Und das zum erschwinglichen Preis (Stand Jänner 2017: knapp über € 120,- für den Unifi UAP AC Mesh und etwa € 200, für den Unifi UAP AC Mesh Pro).

UAP AC Mesh

Der Unifi UAP AC Mesh hat das Potenzial, mein neues Standardgerät zu werden. Es ist auch für den Innenbereich fesch, bietet alle gängig benötigten Technologien und unterstützt die PoE Varianten “24V Passive PoE” und “802.3af Alternative A”, wodurch es im Privatbereich günstig eingesetzt, aber auch an bestehende Switches im Firmenbereich angeschlossen werden kann:

  • ein Gerät für indoor & outdoor
  • lässt sich mit vielen bestehenden PoE-Switches nutzen, da es zwei Standards für die PoE-Versorgung unterstützt:
    • 24V Passive PoE (alter Ubiquiti/Mikrotik/etc. Standard)
    • 802.3af (Alternative A; vmtl. auch an 802.3at nutzbar)
  • unterstützt beide WLAN Frequenzen: 2,4 GHz und 5 GHz
  • erfüllt mit 802.11ac und 2×2 MIMO die modernsten WLAN-Standards mit Geschwindigkeiten bis 867 MBit/s. Und ist kompatibel zu 802.11a/b/g/n/ac.
  • bindet sich in bestehende Unifi-Management-Umgebungen ein und bietet somit zentrale Konfiguration & Monitoring. Optional kann der AP selbstständig mit unabhängiger lokaler Konfiguration betrieben werden.
  • abnehmbare Antennen. Der APs enthält Montagevorrichtungen, um mit externen Antennen zB. für bestehende Sektor- oder Panelantennen betrieben zu werden.
  • VLANs und 802.1q. Für mich immer wichtig, mehrere Netze über VLANs zuführen zu können und als separate SSIDs auszusenden (4 SSIDs sind gleichzeitig je Frequenz je AP möglich, die beiden Frequenzen können für unterschiedliche SSID-Konfigurationen genutzt werden)

Außerdem kann der UAP AC Mesh an vorhandene Wandhalterungen oder Antenna mounts  (zB. AirMax Antennen oder Unifi Sektor-Antennen) montiert werden (zB. für die Rocket-Serie).

UAP AC Mesh Pro

Was mir zum Unifi UAP AC Mesh Pro als erstes auffällt: er ist erheblich größer! 34,32×18,12 cm ergeben eine ziemlich eindrucksvolle Fläche, für eine Außenmontage auf einem Mast werde ich hier die Windlast speziell berücksichtigen.

Obwohl das Gerät wie eine Panelantenne aussieht, handelt es ich um einen Rundstrahler. Drei Antennen mit 8 dbi Gewinn sind verbaut, wodurch 3×3 MIMO möglich ist und nominal 5 GHz 802.11ac 1.300 MBit/s (1,3 GBit/s!), sowie für 2,4 GHz 450 Mbit/s möglich werden. Natürlich werden die Bandbreiten nur erreicht, wenn auch das Endgerät das Senden und Empfangen über 3 Antennen ermöglicht.

Hinsichtlich PoE wird beim Pro nur 802.3af unterstützt.

Erwähnenswert ist noch, dass der Pro über zwei Gigabit-Ethernet-Ports verfügt, wodurch es möglich ist, weitere Access Points “hinter” dem Unifi UAP Mesh Pro zu betreiben (Daisy Chain).

Mesh?

Ich finde den Namen “Mesh” etwas verfänglich: bei Mesh Network denke ich immer an Netztopologien ähnlich zu Funkfeuer. Also zu weit verteilten Netzen, wo WLAN-Systeme oder -Knoten mit mehreren anderen Systemen oder Knoten verbunden sind.

Für die hier beschriebenen Produkte finde ich das nicht ganz passend: Unifi Systeme können zwar über “Wireless Uplink” einen Access Point über einen anderen AP anbinden. Allerdings kann ein AP, der nur ohne Kabel verbunden ist, das Signal nicht an noch einen weiteren AP weiterreichen.
(Update Februar 2017: siehe Kommentar von Harry unten, es ist bei den Mesh-Produkten möglich, auch mehrere Access Points untereinander über Wireless Uplink zu verbinden: https://help.ubnt.com/hc/en-us/articles/115002262328-UniFi-Feature-Guide-Wireless-Uplink).

Unpacking

Ich habe mich bemüht, recht zeitig nach Erscheinen der Produkte zwei Unifi UAP AC Mesh zu bestellen, da ich schon dringend ein paar Außenbereiche mit WLAN versorgen müsste, das aber bisher nur halbherzig gemacht habe, da ja die bisher verfügbaren Produkte nicht zufriedenstellend waren.

Ubiquiti hat scheinbar das Design des Zubehörs angepasst. Neu ist nämlich, dass das Netzteil und das Kabel weiß – wie der AP selbst – sind. Das Netzteil entspricht den Spezifikationen der bisherigen Produkte für 24V Gigabit passive PoE (0,5 A), ich finde abgesehen von Farbe (und der abgerundeten Form) keine technischen Unterschiede. Jedenfalls möchte ich darauf hinweisen, dass – obwohl ältere Netzteile funktionieren – darauf geachtet werden soll, dass Gigabit unterstützt wird. Schließlich ermöglicht der Access Point ja Bandbreiten, bei denen man nicht möchte, dass dann das Netzteil zum Flaschenhals wird.

Ansonst wirkt der Access Point robust, die beiden Antennen sind abschraubbar (RP-SMA-Anschlüsse). Es können also jederzeit externe Antennen angeschlossen werden. UAP AC Mesh können gemeinsam mit AirMax-Antennen oder -Sektor-Antennen genutzt werden, die bisher zB. für die Rocket-Produkte oder Outdoor+/Outdoor5  gedacht waren.

Eine Signal-LED auf der Seite des Access Points zeigt – wie auch bei anderen Unifi-Produkten üblich – den Status des Access Points:

Das Einbinden in den Unifi Controller funktioniert problemlos. Das Gerät wird sofort erkannt, ein Software-Upgrade wird angeboten und man kann es problemlos adoptieren. ich habe das richtige Profil zugewiesen und kurz darauf haben sich schon die ersten Clients verbunden. Fertig.

Das ging wirklich so schnell, dass ich dann noch versucht habe, den Unifi UAP AC Mesh über einen Wireless Uplink einzubinden. Auch hier hat alles klaglos funktioniert.

Die Signalstärken sind einwandfrei: auch mit zwei Wänden und einem Abstand von 25 Metern zum Access Point bekomme ich -65 dB angezeigt.

Fazit

Ich werde wohl vermehrt auf den Unifi UAP AC Mesh setzen, nachdem er universell in Gebäuden wie im Freien eingesetzt werden kann. Der Unifi UAP AC Mesh Pro bietet in Umgebungen mit vielen Clients aufgrund der zusätzlichen Antenne Vorteile, ich habe jedoch kaum Umgebungen, bei denen ich > 30 Geräte je AP versorgen muss.

Ubiquiti UniFi AC Access Points kurz betrachtet

In einem früheren Beitrag habe ich bereits beschrieben, warum ich baulich für eine ordentliche WLAN-Versorgung in meiner Wohnung ein ordentliches WLAN-System möchte.

Ich habe mich ja damals für ein Unifi System von Ubiquiti entschieden und das nie bereut. Auch die Migration zur “neuen Generation” (Wave 2?) von Unifi AC Geräten (AC = sie unterstützen den aktuellen WLAN-Standard 802.11ac) hat problemlos funktioniert.

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.

Hier möchte ich einen die Vor- & Nachteile der einzelnen Produkte diskutieren und meine Erfahrung im Einsatz beitragen.

Folgende Access Points gibt es in dieser Reihe:

  • der Ubiquiti Unifi UAP AC LITE ist übrigens mein Favorit, weil er im Normalfalls ausreichend ist
  • der Unifi UAP AC LR ist das Long Range-Modell mit höherem Antennengewinn und dadurch besserer Reichweite
  • der Unifi UAP AC PRO ermöglicht mit 3×3 MIMO höhere Bandbreiten (kommt aber nur in Frage, wenn die Endgeräte 3×3 MIMO unterstützen)
  • Unifi UAP AC EDU für Campus-Umgebungen ermöglich Durchsagen über eingebaute Lautsprecher

Leider habe ich keine Anwendung für einen Unifi UAP AC EDU und daher keinen testen können.

Unifi UAP AC Lite

Damit fange ich gleich mit meinem Favoriten an: dem Unifi UAP AC LITE Access Point.

Der AC Lite unterstützt beide Frequenzbänder (2,4 GHz und 5 GHz), natürlich den neuen 802.11ac-Standard (ist aber auch kompatibel zu älteren WLAN-Standards 802.11a/b/g/n/ac), liefert mit 2×2 MIMO im 5 GHz-Band bis zu 867 MBit/s zu den Clients und ist dank 24 V passive PoE mit meinem bestehenden System kompatibel. Im 2,4 GHz Band schafft er 300 MBit/s (802.11n).

Das Gerät ist preisgünstig und kann einerseits als eigenständiges Gerät betrieben werden (Konfiguration über Android App) oder wird in das Unifi-System integriert: damit wird der AP von einem Unifi Controller (zB. Ubiquiti Cloud Key, läuft aber auch zB. auf einem Raspberry oder über eine App im Synology NAS) zentral konfiguriert und gemonitored. Das Anlegen oder Ändern einer SSID in einer Umgebung mit vielen Access Points ist somit sehr bequem zu bewerkstelligen. Je AP und Frequenz werden übrigens 4 SSIDs unterstützt.

Dieser Access Point hat für mich das beste Preis-/Leistungsverhältnis. Er erfüllt alle meine Anforderungen. Ich habe damit auch bereits mehr als 30 WLAN-Geräte gleichzeitig erfolgreich bedient und bisher keine Kapazitätsgrenzen kennengelernt.

Auch beim Roaming mit anderen Unifi AC APs gibt es keine Probleme. Ich verwende dazu kein ZH (Zero Handoff, dabei unterstützen die Access Points den Roaming-Vorgang) und es geht trotzdem wunderbar. Ohne ZH kann jeder AP eine anderen Funkkanal nutzen und stört bzw. überlappt nicht mit den anderen APs.

Unifi UAP AC Pro

Der AC Pro Access Point ist dem LITE sehr ähnlich, unterstützt jedoch 3×3 MIMO, wodurch er 1.300 MBit/s (1,3 GBit/s!) zu den Endgeräten verspricht und wird durch PoE (802.3af oder 802.3at) versorgt. Eine Versorgung durch 24 V PoE ist nicht möglich.

Hinsichtlich Management unterstützt der AP Pro alle oben genannten Methoden.

Unifi UAP AC LR

Die Long Range-Version beinhaltet eine Antenne mit höherem Gewinn. Das ist ermöglicht in vielen Ländern eine höhere Reichweite beim Senden. Da in Österreich (und wie ich glaube in der ganzen EU) die Sendeleistung nach EIRP beschränkt ist, darf der AC LR bei korrekter Ländereinstellung bei uns nicht mit voller Leistung senden.

Die “bessere” Antenne wirkt aber auch empfangsseitig. Und das ist aus meiner Sicht die große Stärke dieses Modells. In schwierigen Umgebungen (zB. Gebäuden mit dicken Mauern) habe ich damit erheblich bessere Ergebnisse erzielt (Bandbreite und Stabilität). Ich bin teilweise ganz erstaunt gewesen, wie zuverlässig der AP LR über große Entfernungen in Gebäuden noch problemlos funktioniert hat.

Fazit: ich empfehle ja normalerweise immer den Ubiquiti Unifi UAP AC LITE, aber für schwierige Funksituationen empfehle ich, auf den Unifi UAP AC LR auszuweichen.

Erfahrungen

Meine Erfahrungen mit diesen Geräten sind jeweils top. Sie funktionieren zuverlässig, haben höchste Kompatibilität (es hat nie Probleme gegeben, dass sich jemand nicht verbinden konnte) und das Management über den Unifi Controller, den ich unter Ubuntu Linux laufen habe, funktioniert super!

Ich verwende die APs gemeinsam mit einem UAP Outdoor und einer Picostation M2 HP und habe auch beim Roaming keine Probleme. (Anmerkung: Der Outdoor+ und die Picostation unterstützen nur 2,4 GHz.  Falls jemand gute Outdoor-APs sucht, gibt es hier in Kürze einen Artikel über die neuen Unifi UAP Mesh (Nachtrag Jänner 2017: der Beitrag ist mittlerweile verfügbar). Die sind moderner und daher empfehlenswerter als der Outdoor+ und die Picostation.)

Näheres zu meiner Konfiguration mit dem Unifi Controller habe ich in einem älteren Beitrag beschrieben. Die Produkte dort sind mittlerweile veraltert, aber die Funktionen des Controllers sind weiterhin gültig.

Ich betreibe mit den Access Points einen Funkfeuer-Hotspot und sehe eigentlich jeden Tag einzelne User, die den Dienst nutzen. Für den Hotspot wird auch eine Landing Page vorgeschaltet und dann ein Redirect auf www.funkfeuer.at erzwungen. Alles funktioniert seit Monaten einwandfrei. (Das System schon über einem Jahr, aber die UAP ACs habe ich erst ein halbes Jahr damit im Einsatz).

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…

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.

Unifi AP-AC-Pro: erste Eindrücke

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.

Aktivieren von radvd am Ubiquiti Edgerouter für IPv6 Prefix Delegation

Ich nutze immer noch gerne und erfolgreich den Ubiquiti Edgerouter X SFP als Router in meinem LAN.

Da ich über Funkfeuer ja auch IPv6 nutzen kann, möchte ich das nun in meinem LAN einrichten und offizielle IPv6-Adressen (ohne NAT) den Endgeräten zuweisen.

Die IPv6-Adressen an den Interfaces lassen sich ja problemlos über das Webinterface konfigurieren. Aber es gibt im Webinterface keine Möglichkeit zu stateless oder stateful IPv6-Adressvergabe (zB. über DHCPv6 oder radvd). Dazu muss man kurz über SSH einloggen und die Kommandos textbasiert eingeben.

Routing ist ja praktischerweise aufgedreht. Dass alles funktioniert, habe ich getestet, indem ich meinem PC eine IPv6-Adresse aus meinem LAN-Bereich statisch vergeben habe. Zugriff auf Webseiten über IPv6 hat sofort klaglos funktioniert.

Also habe ich mit diesen zwei Zeilen rasch radvd auf dem LAN-Interface (bei mir eth1) aktiviert:

configure
set interfaces ethernet eth1 ipv6 router-advert prefix ::/64
set interfaces ethernet eth1 ipv6 router-advert radvd-options "RDNSS 2001:4860:4860::8888 {};"
commit
save

…und schon bekommen Geräte (teilw. sogar ohne neu verbinden zu müssen) IPv6-Adressen vergeben und nutzen IPv6!

Testen kann man das schnell über einen Aufruf auf http://ip6.me – dort wird die IPv6-Adresse angezeigt, falls man über IPv6 hinsurft. Falls eine IPv4-Adresse aufscheint, funktioniert etwas mit dem IPv6 noch nicht und das Endgerät ist selbstständig zu IPv4 zurückgekehrt.

Mit dem Thema IPv6 Firewall sollte man sich noch auseinander setzen, falls man nicht möchte, dass intern plötzlich alles über öffentliche IPv6-Adressen erreichbar ist…
Einen Vorschlag dazu gibt es zB. hier: https://community.ubnt.com/t5/EdgeMAX/1-6-DHCPv6-PD-with-RDNSS-on-Telenet-in-Belgium/td-p/1100485 Dieses Beispiel hat bei mir einwandfrei funktioniert, um eingehende Verbindungen abzulehnen:

configure
set firewall ipv6-name WANv6_IN default-action drop
set firewall ipv6-name WANv6_IN description 'WAN inbound traffic forwarded to LAN'
set firewall ipv6-name WANv6_IN enable-default-log
set firewall ipv6-name WANv6_IN rule 10 action accept
set firewall ipv6-name WANv6_IN rule 10 description 'Allow established/related sessions'
set firewall ipv6-name WANv6_IN rule 10 state established enable
set firewall ipv6-name WANv6_IN rule 10 state related enable
set firewall ipv6-name WANv6_IN rule 20 action drop
set firewall ipv6-name WANv6_IN rule 20 description 'Drop invalid state'
set firewall ipv6-name WANv6_IN rule 20 state invalid enable
set firewall ipv6-name WANv6_IN rule 30 action accept
set firewall ipv6-name WANv6_IN rule 30 description 'Allow IPv6 icmp'
set firewall ipv6-name WANv6_IN rule 30 protocol ipv6-icmp

set firewall ipv6-name WANv6_LOCAL default-action drop
set firewall ipv6-name WANv6_LOCAL description 'WAN inbound traffic to the router'
set firewall ipv6-name WANv6_LOCAL enable-default-log
set firewall ipv6-name WANv6_LOCAL rule 10 action accept
set firewall ipv6-name WANv6_LOCAL rule 10 description 'Allow established/related sessions'
set firewall ipv6-name WANv6_LOCAL rule 10 state established enable
set firewall ipv6-name WANv6_LOCAL rule 10 state related enable
set firewall ipv6-name WANv6_LOCAL rule 20 action drop
set firewall ipv6-name WANv6_LOCAL rule 20 description 'Drop invalid state'
set firewall ipv6-name WANv6_LOCAL rule 20 state invalid enable
set firewall ipv6-name WANv6_LOCAL rule 30 action accept
set firewall ipv6-name WANv6_LOCAL rule 30 description 'Allow IPv6 icmp'
set firewall ipv6-name WANv6_LOCAL rule 30 protocol ipv6-icmp
set firewall ipv6-name WANv6_LOCAL rule 40 action accept
set firewall ipv6-name WANv6_LOCAL rule 40 description 'allow dhcpv6'
set firewall ipv6-name WANv6_LOCAL rule 40 destination port 546
set firewall ipv6-name WANv6_LOCAL rule 40 protocol udp
set firewall ipv6-name WANv6_LOCAL rule 40 source port 547
commit
save

Danach gehören die Einstellungen noch auf die Interfaces gebunden:

configure
set interfaces ethernet eth0 firewall in ipv6-name WANv6_IN
set interfaces ethernet eth0 firewall local ipv6-name WANv6_LOCAL
commit
save

Ein Test aus dem Internet (zB. Portscan vor dem Setzen der Regeln in Vergleich zu nachher) hat ergeben, dass die Ports nun von außen nicht angesprochen werden können.

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.