Schlagwort-Archive: Linux

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.

Ubiquiti EdgeRouter X mit PPTP Server und lokaler Authentifizierung

Der Ubiquiti EdgeRouter X SFP sieht nach dem perfekten Gateway für meinen Funkfeuer-Zugang zu Hause aus!

Aufgrund der mipsel-Architektur und den debian-Images als Basis der EdgeRouter-Serie besteht die Möglichkeit, die mipsel-Pakete für olsrd und olsrd-plugins manuell nachzuinstallieren und somit das Routingprotokoll für Funkfeuer direkt mitlaufen zu lassen. Dies funktioniert wunderbar für IPv4 und IPv6!

Außerdem ist das Gerät als softwarebasierter 6-Port-Router (5 + 1 SFP) mit PoE-Unterstützung auf 5 Ports ideal für zu Hause und ich kann einzelne Antennen auch direkt mit Strom versorgen.

PPTP Server

Aber nun zu PPTP. Vorab: PPTP ist wohl das unsicherste VPN-Protokoll, das man wählen kann. Es ist aber auch das am einfachsten zu konfigurierende und bei Windows direkt konfigurierbar (= ohne etwas installieren zu müssen).

Bei den folgenden Schritten habe ich mich stark an diesem Youtube-Video orientiert: https://www.youtube.com/watch?v=XqFcPv2lfDI

Die Konfiguration erfolgt über die Kommandozeile, also per SSH oder indem man in der Weboberfläche (GUI) auf „CLI“ klickt.

configure
set vpn pptp remote-access authentication mode local
set vpn pptp remote-access authentication local-users username meinbenutzer password meinpasswort

Die letzte Zeile wiederholt man für alle Benutzer, denen man Zugang gewähren möchte.

set vpn pptp remote-access client-ip-pool start 192.168.1.81
set vpn pptp remote-access client-ip-pool stop 192.168.1.89
set vpn pptp remote-access outside-address 78.41.113.xxx
set vpn pptp remote-access dns-servers server-1 192.168.1.1
set vpn pptp remote-access dns-servers server-2 208.67.222.222

Einige Firewall-Regeln gehören noch gesetzt:

set firewall name WAN_LOCAL rule 30 action accept
set firewall name WAN_LOCAL rule 30 description allow_PPTP
set firewall name WAN_LOCAL rule 30 destination port 1723
set firewall name WAN_LOCAL rule 30 log disable
set firewall name WAN_LOCAL rule 30 protocol tcp
set firewall name WAN_LOCAL rule 40 action accept
set firewall name WAN_LOCAL rule 40 description allow_PPTP_GRE
set firewall name WAN_LOCAL rule 40 log disable
set firewall name WAN_LOCAL rule 40 protocol GRE

Mit den folgenden Kommandos wird die Änderung aktiviert und gespeichert. Mein erster Test war danach sofort erfolgreich!

commit
save

Test mit Windows 7

Auf meinem Windows7-PC habe ich sofort ein VPN hinzugefügt:

  1. Systemsteuerung -> Netzwerk und Freigabecenter
  2. Neue Verbindung oder neues Netzwerk einrichten
  3. Verbindung mit dem Arbeitsplatz herstellen
  4. Die Internetverbindung (VPN) verwenden
  5. Internetadresse: meine externe IP bzw. Hostname des EdgeRouters
  6. Zielname: frei wählbar, zB. „PPTP EdgeRouter“
  7. Benutzername & Kennwort eingeben, so wie die Authentifizierungsinfo am EdgeRouter programmiert wurde; es muss keine Domäne angegeben werden.
  8. auf „Verbinden“ klicken. Fertig!

Ich war sofort verbunden. Als IP-Adresse habe ich eine IP aus dem konfigurierten Pool erhalten! Internetsurfen war möglich! Ich habe meine IP über http://ip4.me überprüft und dort scheint die externe IP des EdgeRouter auf. Ich bin also über das PPTP-VPN und den EdgeRouter im Internet!

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.

Der Stromverbrauch meiner Kaffeemaschine

edimax2101wJetzt kann ich dank fhem und des Edimax 2101W den Stromverbrauch meiner Haushaltsgeräte messen. Und begonnen habe ich, wie ihr wisst, mit der Nespresso Kaffemaschine:

edimax-fhem-kaffeemaschinenverbrauch

Die obere Grafik zeigt jeweils den Monatsverbrauch in kWh. Die untere Grafik zeigt den jeweils aktuellen Stromverbrauch in Watt. Die Granularität ist 30 Sekunden.

Hier eine detailliertere Ansicht (gezoomt):

edimax-nespresso-detailverbrauch

Was können wir aus diesen zwei Grafiken ableiten:

  • das Aufheizen der Maschine benötigt weniger als 1 Minute und „zieht“ 1100-1200 Watt
  • für das Halten der Temperatur benötigt die Maschine immer wieder bis zu 400 Watt
  • wenn ich mir einen Kaffee mache, zeigt der Edimax 2101W kurz 45 Watt an, ich vermute hier die Pumpe, etc

Daraus ergibt sich in kWh:

  • für’s Aufheizen verbraucht die Maschine etwa 0,003-0,005 kWh (= 3-5 Wh)
  • inkl. Aufheizen und einer Stunde Betrieb verbraucht die Maschine zirka 0,016 kWh (16 Wh)
  • für jede weitere Stunde verbraucht die Maschine 0,0091 kWh (= 9,1 Wh

Strom messen mit FHEM und Edimax 2101W

Ich wollte immer schon wissen, wieviel Energie die Geräte im Haushalt verbrauchen. Waschmaschine, Kaffeemaschine beim Aufheizen, Computer, SAT Receiver, meine Funkfeuer-Installation am Dach, etc… Anwendungsbereiche hätte ich viele.

Ein Energiemessgerät mit Anzeige oder Logger auf SD-Karte hat meine Ansprüche nicht ganz zufriedengestellt. Natürlich möchte ich die Daten automatisch und zeitnah auslesen und darstellen.

Toll, dass das nun möglich ist und dass es sich in FHEM, meiner zentralen Software für die Hausautomatisierung, einbinden lässt.

Einrichtung

edimax2101wHeute Früh hat die Post meinen Edimax 2101W, gekauft um knapp weniger als € 50,-, zugestellt. Es handelt sich dabei um einen Zwischenstecker für Steckdosen, der per WLAN verbunden ist und über eine Android-App geschaltet (ein/aus), konfiguriert (Zeitschaltfunktionen, WLAN-Zugangsdaten) und ausgelesen (Energieverbrauch) werden kann.

Das Gerät sendet nach dem Anstecken an einer Steckdose eine SSID als Master (Access Point) aus. Ich verbinde mich mit meinem Android Tablet zu dieser offenen SSID, starte die EdiMax-App und konfiguriere die SSID und das Kennwort für mein WLAN, damit der Edimax 2101W sich nach einem Reboot in mein Hausnetz integriert. Meinem DHCP-Server am Router habe ich eine feste IP-Adresse für die MAC-Adresse des Edimax Gerätes eingestellt, damit sich diese nicht ändert und ich per Hausautomatisierung das Gerät abfragen kann.

Einbindung FHEM

In FHEM gibt es seit ein paar Wochen ein fertiges Modul für die Einbindung des Edimax 2101W. Es ist nicht mehr zu tun, als das Gerät mit einem einzeiligen Kommando einzubinden:

define SmartPlugCpower EDIPLUG 192.168.1.23

FHEM nimmt nun für die Authentifizierung die  Standardwerte admin/1234 an und liest sofort alle Daten aus:

fhem-edi-examplelines

Für die Verbesserung der Darstellung (va. am Floorplan) habe ich noch folgende Zeilen konfiguriert:

define SmartPlugCpower EDIPLUG 192.168.1.23
attr SmartPlugCpower eventMap on:an off:aus
attr SmartPlugCpower interval 60
attr SmartPlugCpower model SP2101W
attr SmartPlugCpower password 1234
attr SmartPlugCpower room Wohnzimmer
attr SmartPlugCpower user admin

Natürlich möchte ich die Werte in einer Datei loggen und auch als SVG zeichnen. Danke an’s FHEM Forum für die wichtigen Hinweise zu diesem Thema:

define FileLog_SmartPlugCpower FileLog ./log/SmartPlugCpower_01-%Y-%m.log SmartPlugCpower

define SVG_SmartPlugCpower SVG FileLog_SmartPlugCpower:SVG_FileLog_SmartPlugCpower:CURRENT
attr SVG_SmartPlugCpower room Wohnzimmer

define SVG_FileLog_SmartPlugCpower_Monat SVG FileLog_SmartPlugCpower:SVG_FileLog_SmartPlugCpower_Monat:CURRENT
attr SVG_FileLog_SmartPlugCpower_Monat room Wohnzimmer

fhem-edi-gplot

Die Liste der Anpassungen:

  • Y-Axis label left entfernt
  • Y-Axis label right auf „Watt“ geändert
  • im Diagramm die Sources der ersten Zeile auf „Verbrauch Watt“ geändert
  • statt der standardmäßigen Regex auf SmartPlugCpower.power_now geändert, weil das der Wert ist, den ich sehen will.

Durch Klicken auf „Write .gplot file“ wird die Einstellung aktiviert und eine Grafik erstellt.

Für die Monatsgrafik habe ich die gleichen Zeilen angepasst, die Einheit ist allerdings „kWh“:

fhem-edi-gplot-kwh

Ich mach‘ mir mal einen Kaffee

Ich hab‘ also einmal die Nespresso Kaffeemaschine angeschlossen und mir zwei Espressi gemacht:

fhem-ediplug-kaffeemaschine

Nach dem Einschalten beim Aufzeihen der Maschine werden kurz immerhin 1.200 Watt benötigt:

2015-07-16_06:49:43 SmartPlugCpower ON / 1201.70 W / 5.3106 A

Auch zwischendurch heizt die Maschine immer wieder kurz nach und hat in 1,5 Stunden (aufzeihen, zwei Espressi + 1,5h Leerlauf, danach abgeschaltet) immerhin 0,031 kWh verbraucht.

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.