PRTG mit Ubiquiti WLAN Access Points

Ein Sammelsurium von WiFi AP und zweckentfremdeten DSL-Routen mit zweifelhaften Reichweiten macht letztlich kein Spaß beim Einsatz von WiFi in den eigenen vier Wänden. Natürlich ist es ein Unterschied, ob man ein billiges Gerät unter 50€ kauft, die angeblich alles können (inklusive Radius und VLAN und am Besten noch DSL) oder ein Enterprise-System mit Controller für Hunderte oder gar über tausend Euro. Und dann hat mich ein Kollege auf Ubiquiti aufmerksam gemacht. Es wird "Enterprise-Technik" zu einem fairen Preis versprochen. Diese Seite beschreibt meine Erfahrungen und die Integration in PRTG.

Ich nutze seit vielen Jahren ein Setup auf zwei AC Lite-APs und dem Controller auf Windows. Die Entwicklung geht natürlich weiter. Prüfen Sie, welche aktuellen Produkte ihren Anforderungen am besten entsprechen.

Monitoring Ubiquiti UniFi WiFi with PRTG: Total Insight into UniFi Environments
https://blog.paessler.com/monitoring-ubiquiti-unifi-wifi-with-prtg-total-insight-into-unifi-environments
PRTG hat meinen Sensor in einem Blog-Artikel gewürdigt. Vielen Dank

Die Hardware

Ubiquiti hat eine ganze Serie von Hardware für drinnen und draußen, mit unterschiedlicher Leistung und Größe. Aber alle sollen irgendwie "gleich" funktionieren. Sie sind zuerst einmal "NUR WLAN-Accesspoint". Es gibt kein VoIP, kein DSL, keine USB-Anschlüsse für Festplatten, keine analogen oder ISDN Anschlüsse und es ist auch kein Netzwerk-Switch. Nicht mal einen Stromeingang haben meine Geräte. Über das einzige RJ-45 Kabel kommt LAN und auch die Energieversorgung. Das Netzteil wird beim Switch platziert und speist dort ein, wenn der Access-Point und Switch nicht selbst mit PoE arbeiten.


Diese Übersicht veraltet meist schnell. Bitte informieren Sie sich beim Hersteller

Achten Sie darauf: Es gibt auch welche ohne das "AC". Die haben dann "nur" 2,4 GHz. Der UAP-AC-LR kostet ca. 110€. Es gibt auch "Outdoor"-Accesspoints. Interessant ist in dem Fall natürlich die Funkausleuchtung. Hier hilft aber die FCC weiter, bei der Gerätehersteller ihre Konformität belegen müssen. Eine Suche z.B. nach dem "Product Code: -uap" ergibt acht Geräte, bei denen einige auch "Antenna Spec" enthalten.

Entsprechend kann man sich überlegen, wie man seinen Access-Point montiert. Auf dem Bild steht Grün für die vertikale und blau für die horizontale Polarisation im 5 GHz-Bereich:

Man sieht schon, dass der Access-Point je nach Polarisationsrichtung eine Fokussierung erlaubt. Leider hat das FCC z.B. keine Daten zur Fritz!Box.

Was ist drin?

Ich habe mal einen Portscan auf einen AP gemacht und es war einzig der Port 22/SSH offen. Über PUTTY (Siehe Terminalclient) können Sie sich verbinde und mit dem Admin-Kennwort anmelden. Viel mehr als den Status könne Sie so nicht bekommen.

Das System basiert auf BusyBox (https://busybox.net/about.html). Ich bin sicher, dass per SSH hier noch viel mehr Befehle möglich sind oder die Box über die "Set-Inform"-URL mit dem zentralen Management spricht und so ihre Daten bekommt. Ich habe auf dem Access Points selbst keine Einstellungen bezüglich SNMP oder REST-Services gefunden, die man direkt z.B. mit PRTG ansprechen könnte.

Man könnte überlegen die INFORM-Posts, die alle 10 Sekunden gesendet werden, zu analysiere. Allerdings sind die Pakete anscheinend GZIP komprimiert und AES verschlüsselt.

Standalone-Mode und Management mit App

Der AccessPoint hat keine Weboberfläche. Wer den AP einzeln betreiben will, kann dazu aber die APP verwenden. Wer wenige APs hat, auf VLANs und Bandbreitenbeschränkungen etc. verzichten will, kann einen AP Innerhalb von wenigen Minuten eingerichtet. Die App meldet sich mit den Default Anmeldedaten "ubnt/ubnt" an und nachdem Sie SSID und Kennwort eingetragen haben, wird beim Speichern auch der Anmeldename und Kennwort auf die Einstellung geändert, die Sie in der App vorgenommen haben. Wer so also mehrere APs installiert, hat allen auch das gleiche Kennwort verpasst. Die App "findet" alle diese APs einfach im LAN und sie können direkt sehen, wer mit dem jeweiligen AP verbunden ist und können einzelne Geräte je AP blockieren.

Die APs haben durch ihre Statusmeldungen auch den Vorteil, dass quasi jede Putzkraft, Elektriker oder Mieter sofort erkennen kann, ob technisch alles i.O. ist. "Blaues Licht" bedeutet in Ordnung. Alle anderen "Blick Codes" sind auch gut erklärt. Wer schon mal mehrere davon installiert hat, wird dies zu schätzen wissen. Auch die Netzteile, die PoE einspeisen haben eine LED die blinkt bzw. unterschiedlich hell leuchtet. So erkennen Sie gut, ob auch die elektrische Verbindung "steht"

Management mit dem Unifi Controller

Interessant wird der Betrieb aber in Verbindung mit einer Management Software, die es für Mac, Unix und Windows gibt. Die Plattformunabhängigkeit dürfte auch darin begründet sein, dass die Software eine Java Runtime voraussetzt. Sie "findet" neue APs und mit einem Klick ist der AP in das Management eingebunden. Die Applikation gibt es aber auch als fertigen Stick, wenn Sie keinen Computer bereitstellen wollen.

Alternativ können Sie die Software natürlich selbst betreiben. Das kann auch ein Raspberry oder Docker sein

Über das Management ist dann sehr viel mehr möglich, als allein über die App erreichbar ist. Dennoch ist die App nicht obsolet, denn über die App kann ich mich auch mit der Management-Software verbinden und den Status des gesamten Netzwerks betrachten. Das geht natürlich auch über einen Browser. Auf der Management-Station sieht man nur ein Fenster:

Wenn Sie dies minimieren, dann bleibt ein kleines Icon in der Taskleiste. Sie können das Management-Programm auch als Windows Service einrichten.

Die Schritte in Kurzform sind:

REM Bitte zuerst ein Backup der Installation machen. Updates koennen schief gehen.
cd "%UserProfile%\Ubiquiti UniFi\"
REM Ggfls. bestehenden Dienst stoppen und deregistireren
java -jar lib\ace.jar stopsvc
java -jar lib\ace.jar uninstallsvc
REM nun die Updates durchführen ggls. auch JavaUpdate
REM dann den Controller als Dienst einrichten und starten.
java -jar lib\ace.jar installsvc
java -jar lib\ace.jar startsvc

Wer nun Angst hat, dass damit ein Single Point of Failure entstehen könnte, kann beruhigt sein. Die kleinen APs machen ihre Arbeit auch ohne die aktive Management-Lösung. Es gibt den Controller natürlich auch als "Cloud-Lösung".

Hinweis:
Im Internet finden Sie immer umfangreiche Abbildung des Management mit sehr vielen Bildern und Graphen. Einige Daten sind nur mit einem zusätzlichen "Gateway" möglich. Für Firmen sicher interessant aber für den Hausgebrauch eher nicht. Das Unifiy Secure Gateway kann nicht als Controller dienen. Einen PC, auf dem zumindest zur Konfiguration der Controller mal gestartet wird, ist immer erforderlich. Er muss aber nicht im gleichen LAN stehen.

Der Zugriff erfolgt über einen Browser oder die App. Über den Browser landen Sie in einem Assistenten, mit dem Sie Benutzername und Kennwort des "Admin" festlegen müssen, der später neue APs addiert. Sie können später weitere "Administrator" oder "Read-Only User" addieren. Nach der Anmeldung landen Sie in einem Dashboard, welches aber in einem Netzwerk ohne Gateway kaum Daten liefert:

Interessanter ist da schon die zweite Seite mit den Statistiken:

 

Oder die Liste der Clients

Controller und AP finden sich im gleichen LAN eigentlich alleine. Sie können das aber auch durch DHCP-Einträge oder DNS-Einträge unterstützen. Die Controller nutzen DHCP um z.B. das VLAN zu ermitteln und eine IP-Adresse zu bekommen. Wenn Sie die IP-Adresse des Controller mit dem Namen "ubiquiti.<ihredomain>" im DNS eintragen, dann findet der Access Point den Controller auch über Router hinweg.

Controller im Internet

Wer nur einen Standort betreibt, kann dort ja gerne einen Controller als PC oder Cloud Key aufstellen und die APs daran anmelden, Was macht man aber, wenn man mehrere Standorte hat, die nicht per Routing verbunden sind. Angenommen Sie haben ihren Firmenstandort und zudem verteilen Sie in den Home-Offices ihrer Mitarbeiter entsprechende APs. Auch dann scheint es eine Lösung zu geben auch wenn ich die noch nicht umgesetzt habe.

Die APs nutzen die URL "http://unifi:8080/inform" um den Controller über ihre Existenz zu informieren. Wenn im LAN dieser "kurze Name " auf die öffentlichen IP-Adresse ihres Controllers verweist, dann sollte das auf anhieb funktionieren. In einem Homeoffice haben Sie aber meist keinen DNS-Server und DSL-Roter, sei es die normale Fritz!Box und erst recht nicht die Speedport-Fraktion, erlauben lokale HOSTS-Einträge. Ein Lob auf die OpenWRT-Plattform. Aber Sie können per SSH dem AccessPoint auch einen FQDN verpassen. Alternativ geht es auch per DHCP Option 43. Das geht leider nicht über die App und selbst per SSH muss man das wohl nach dem "Adopt" noch mal machen, da durch die Verbindung mit dem Controller die Konfiguration ersetzt wird

set-inform http://<external.IP.address.controller>:8080/inform

Zudem muss der Controller über die Port 8080 (HTTP) und 3478 (STUN) erreichbar sein. Das ist natürlich auch eine pfiffige Lösung für z.B. Ferienwohnungen, die mehrere AccessPoints hinter unterschiedlichen DSL-Routern betreiben und damit alle über einen Controller steuern und überwachen.

Anscheinend bietet auch Ubiquiti einen "Cloud Service" an (199US$/Jahr) zudem dem ich aber nur 2016 eine Veröffentlichung gefunden habe. Beachten Sie beim Eigenbetrieb, dass Sie sich selbst um die Updates des Controllers aber auch der Plattform darunter Gedanken machen müssen.

Remote Management mit Cloud

Sie können ihren lokalen UBNT Controller per DynDNS o.ä. aus dem Internet erreichbar machen, So können Sie dann auch von Unterwegs ihr System verwalten. Aber Ubiquiti bietet ihnen auch einen Cloud-Zugang an. Dazu verbinden Sie ihren lokalem Controller mit dem Cloud-Service und nutzen dann einfach die Dienste und Ubiquiti als eine Art "Proxy".

Der Zugriff aus dem Internet geht dann ebenfalls über die App oder einen Browser:

Leider funktioniert dies nicht für Standalone-APs, die ohne Controller betrieben werden. Da warte ich ja noch drauf, dass die Controller sich direkt mit der Ubiquiti-Cloud verbinden und gerne auch ein reduziertes Monitoring erlauben.

SNMP - vielleicht

Die APs haben selbst per Default keinen Management Agent aktiv. Über eine Einstellung auf dem Controller kann ich aber SNMP auf den AccessPoints aktivieren.

"Public" ist übrigens kein akzeptierter Community-String. Es darf schon ein anderer Namen sein. Allerdings sollten Sie kein sonst genutztes "Kennwort" verwenden, denn SNMPv1 ist nicht wirklich sicher. Nur gut, dass wohl per SNMP nur gelesen werden kann. Dort läuft dann ein TinySNMP, der Informationen zu dem AccessPoint und den dort aktiven SSIDs liefert.

Enabling SNMP via UniFi Controller GUI turns on the TinySNMPd daemon on each UAP. You query the management IP for the UAPs themselves, not the UniFi Controller IP. Also note that it is SNMP v1 only at present.
Quelle: https://community.ubnt.com/t5/UniFi-Wireless/UniFi-Controller-Monitoring-via-SNMP/td-p/1236566

Über eine Console auf den AP können Sie dies auch kontrollieren. In der /etc/snmpd.conf steht auch die passende Konfigration:

Über einen "netstat -ulnp" ist der Prozess aber auf Port 161/UDP zu sehen

Damit sollte es also kein Problem sein, die Daten mit PRTG auszulesen. Sie sollten aber genau den Community-String angeben, da ansonsten das Device stumm bleibt. Wer eine SNMP Netzwerk-Probe installiert, bekommt dann alle "Netzwerkkarten" zu sehen.

Leider sieht man hier nur die Netzwerke aber weder SSID noch Frequenzband. Da müssen Sie dann schon selbst nachträglich die Zuordnung der Schnittstellen "ath0" bis "ath5" vornehmen. Besser ist es natürlich, wenn man direkt die Ubiquiti-MIBs nutzt, da Ubiquiti einen eigenen Bereich unter "enterprises 41112" hat. Es geht also bei OID repository - 1.3.6.1.4.1 = {iso(1) identified-organization(3) dod(6) internet(1) private(4) enterprise(1) ubiquiti (41112)} los. Hier ein Auszug eines SNMPWALK:

1.3.6.1.4.1.41112.1.6.1.2.1.4.0 = "11" [ASN_INTEGER]
1.3.6.1.4.1.41112.1.6.1.2.1.4.1 = "11" [ASN_INTEGER]
1.3.6.1.4.1.41112.1.6.1.2.1.4.2 = "36" [ASN_INTEGER]
1.3.6.1.4.1.41112.1.6.1.2.1.4.3 = "36" [ASN_INTEGER]
1.3.6.1.4.1.41112.1.6.1.2.1.6.0 = "FC" [ASN_OCTET_STR]
1.3.6.1.4.1.41112.1.6.1.2.1.6.1 = "FCGAST" [ASN_OCTET_STR]
1.3.6.1.4.1.41112.1.6.1.2.1.6.2 = "FC" [ASN_OCTET_STR]
1.3.6.1.4.1.41112.1.6.1.2.1.6.3 = "FCGAST" [ASN_OCTET_STR]
1.3.6.1.4.1.41112.1.6.1.2.1.9.0 = "ng" [ASN_OCTET_STR]
1.3.6.1.4.1.41112.1.6.1.2.1.9.1 = "ng" [ASN_OCTET_STR]
1.3.6.1.4.1.41112.1.6.1.2.1.9.2 = "na" [ASN_OCTET_STR]
1.3.6.1.4.1.41112.1.6.1.2.1.9.3 = "na" [ASN_OCTET_STR]
1.3.6.1.4.1.41112.1.6.3.1 = "192.168.178.12" [ASN_IPADDRESS]
1.3.6.1.4.1.41112.1.6.3.2 = "0" [ASN_INTEGER]
1.3.6.1.4.1.41112.1.6.3.3 = "UAP-AC-Pro-Gen2" [ASN_OCTET_STR]
1.3.6.1.4.1.41112.1.6.3.4 = "eth0" [ASN_OCTET_STR]
1.3.6.1.4.1.41112.1.6.3.5 = "654669" [ASN_COUNTER]

Mit den MIBs kann man in PRTG schon erste Werte ermitteln. Allerdings ist das dann immer ein Blick auf den jeweiligen Access-Point. Ubiqiti und andere Firmenaccesspoints sind aber stark darin, dass es mehrere Accesspoints gibt, die alle die gleichen SSIDs nutzen und einen nahtlosen Übergang von Clients zwischen den Bereichen nicht nur erlauben, sondern geradezu auch erzwingen. Dann ist ein Blick "pro AccessPoint" natürlich nicht so interessant.

802.1x Radius

Die Access Point können mehrere SSIDs verwalten. Leider gibt es bis Juli 2017 noch keine Möglichkeit, auch MAC-Adressen zu beschränken. Wir wissen zwar alle, dass ein Angreifer sehr einfach die MAC-Adresse fälschen kann aber es ist für viele Heimnetzwerke schon eine erste Hürde, wenn unbekannte Geräte, deren Besitzer das WPA2-Kennwort weiß, dennoch nicht "rein" kommen. Bei einer Fritz!Box kann man unter "WLAN -Sicherheit" den Zugang auf "Bekannte Geräte" beschränken und damit Neuanmeldungen zumindest erschweren.

Bei einem Enterprise-Gerät ist dieses Vorgehen natürlich nur bedingt tauglich. Hier macht die Authentifizierung per Radius mehr Sinn, bei der nicht das Gerät sonder der Anwender legitimiert wird. Auch das ist einfach möglich. Unter der globalen Einstellungen des Unify Controllers und "Wireless Network" können Sie pro SSID die Authentifizierung vorgehen. Neben Open, WEP und WPA-PSK gibt es hier auch WPA Enterprise.

Sie brauchen allerdinge einen RADIUS-Server. In einer Firma bietet sich der Aufbau eines Windows IAS-Servers an, der das Active Directory als Quelle nutzt. In kleinen Netzwerken müssen Sie sich eine andere Lösung überlegen. Der Server muss ja 24h auf Antworten reagieren können. Ein FreeRadius auf einem RasPI ist eine Option. Aber wenn Sie ein NAS (Synology, QNAP o.ä.) betreiben, dann könnte hier auch ein Radius-Server seinen Dienst tun.

Controller REST-API

Ubiquiti verfolgt den Ansatz all ihre Geräte über die eigene Controller-Software zu verwalten und die Geräte selbst relativ schlank und einfach zu halten. Im Enterprise-Umfeld ist die durchaus üblich und wer will schon viele Einzelgeräte verwalten. Daher ist es aber umso wichtiger auch von dem zentralen Controller Daten abzufragen. Die Controller-Software bietet dazu eine REST-Schnittstelle an. Zuerst lege ich mir natürlich einen eigenen Benutzer für den Zugriff mittels REST-API an.

Das ist zwar ein Admin aber mit "ReadOnly"-Rechten und einem von mir vorgegebenen Kennwort: Damit ist es nicht mehr ganz so kritisch diese Zugangsdaten in einem Skript zu verwenden.

PRTG Ubiquiti Sample-Sensor

PRTG selbst hat einen Sensor, der per HTTP Daten von einer REST-Schnittstelle ausliest und diese dann in Werte übernimmt. Aber er ist mit dem Feedback der Ubiquiti Controller-Software doch etwas überfordert. Bei Paessler gibt es Script-Sample, welches die interessanten Zahlen regelmäßig per REST ausliest und an PRTG übergibt.

Die statistische Aufbereitung übernimmt dann wieder PRTG. Das Sample in der Version 0.7 vom Sep 2016 hat noch nicht berücksichtigt, dass Ubiquiti die Felder in dem XML umbenannt hat ("num_sta" zu "ng-num_sta" und "guest-num_sta" zu "ng-guest-num_sta". Das ist aber schnell im Code angepasst.

Allerdings liefert das Sample-Skript aus dem PRTG-Forum nur einen Bruchteil der Informationen, die der Ubiquiti-Controller per XML ausliefert.

Erweiterter Sensor für Ubiquiti

Interessant sind sicher auch die Datenmengen, Clients etc. pro virtuellem Netzwerk u.a. Um hier aber den Controller zu entlasten, sollte das Skript einmal die Daten holen und die XML-Information vielleicht speichern. Alternativ könnte das Skript auch einfach die HTTP-Push-Sensor-Technik nutzen  um Detailwerte an mehrere Sensoren aufteilen, z.B. pro VLAN getrennt. Unter dem Knoten ".data.vap_table" gibt es für jedes WLAN und jeden Frequenzbereich durchaus interessante Werte. Hier ein Auszug:

PS C:\> $xmldata.data.vap_table[0]

ccq         : 991
channel     : 11
essid       : WLANSSID
is_guest    : False
is_wep      : False
map_id      :
name        : ath0
num_sta     : 2
radio       : ng
rx_bytes    : 783203
rx_crypts   : 0
rx_dropped  : 1
rx_errors   : 1
rx_frags    : 0
rx_nwids    : 3097
rx_packets  : 5206
state       : RUN
t           : vap
tx_bytes    : 5168168
tx_dropped  : 32
tx_errors   : 0
tx_packets  : 33590
tx_power    : 20
tx_retries  : 384
up          : True
usage       : User

Neben ein paar Statusanzeigen sind hier umfangreiche Statistiken auswertbar. Dies ist nur eine WLAN-SSID auf einem Band. Schon mein einzelner AP liefert aber mit drei SSIDs und zwei Bändern insgesamt sechs dieser Datensätze.

Also habe ich ein eigenes Skript gebaut, welches mit einem Aufruf weiterhin die globalen Daten sammelt und an den aufrufenden Sensor zurück gibt. Damit ist eine allgemeine Überwachung schon mal möglich. Zusätzlich sammelt das gleiche Skript aber auch die Details zu allen einzelnen Funkbereichen und meldet dieser per PRTG:HTTPPush-Sensor an die hinterlegte PRTG-Instanz. Dort muss ich natürlich die entsprechenden Sensoren ebenfalls mit anlegen. In der Übersicht sieht das dann wie folgt aus:

Ich habe mir eine Gruppe "Netzwerk" unter der lokalen Probe angelegt, die für den Empfang der Daten zuständig ist. Der Sensor nach dem obligatorischen PING ist das PowerShell-Script welches einen Überblick erstellt. Die nächsten Sensoren sind HTTPPush-Sensoren die von dem ersten mit Daten gefüllt werden. Gibt gibt es dann je SSID und Frequenzband einen Sensor. Der Übersichtssensor liefert folgende Daten:

Die Übersicht zeigt primär die Anzahl der Access Points (hier 1) und wie viele aktualisierbar sind. Zudem gibt es die generellen Counter für die Anzahl der Clients und der Gäste. Die HTTP-Push-Sensoren bekommen vom gleichen Skript dann aber genauere Daten über die SSID und die Datenmenge.

Alle Daten sind natürlich auch historisch verfügbar. Die Daten verschiedener Sensoren können Sie mit dem Fabric-Sensor natürlich einfach wieder in einem Chart zusammenfassen.

PRTG Sensor einsetzen

Wenn Sie selbst einen Ubiquiti-Controller laufen haben und PRTG nutzen, können Sie gerne mein erweitertes Skript nutzen:

prtg-ubiquiti-msxfaq.1.5.ps1

Die PS1-Datei legen Sie einfach nach "C:\Program Files (x86)\PRTG Network Monitor\Custom Sensors\EXEXML" und können diese dann in PRTG als CUSTOMEXE/XML-Sensor einbinden. Vergessen Sie aber nicht die Parameter korrekt zu übergeben oder gleich im Skript anzupassen.

Sie müssen in der Regel alle Parameter auf ihre Umgebung anpassen. Bei der httppush.url ist in meinem Beispiel der Wert "ubiquiti-" hinterlegt. Daraus leiten sich dann die GUIDs für die Konfiguration des HTTPPush-Sensors ab. Weiter unten im Code finden Sie dann:

Die GUID besteht also aus dem Anfang der URL und dann der Name der SSID und der Frequenz. Wenn Sie das Skript einmal mit "-verbose" interaktiv starten, dann finden Sie die URL recht einfach:

Sie müssen also "irgendwo" einen HTTP-Push-Sensor anlegen, der auf Port 5050 lauscht und die GUID mit dem angezeigten String hat. Beim Aufruf sollte dann "Matching Sensors" auf 1 stehen.

Hinweis:
Ich nutze "Invoke-RestMethod" by Default mit dem Parameter "-SkipCertificateCheck", weil die meisten Controller wohl mit privaten HTTPS-Zertifikaten arbeiten. Der Parameter funktioniert nur mit der PowerShell Core. Ansonsten müssen Sie das Skript anpassen. Siehe Powershell und Zertifikate Check

WiFi und VoIP

Wer heute ein WiFi im Home Office und vor allem in Firmen aufbaut, muss damit planen, dass immer mehr Clients dieses WiFi nutzen und VoIP auch eine Anforderung wird. Die meisten "dünnen" Notebooks und Tablets haben meist nicht mal mehr einen LAN-Anschluss oder nutzen dieses nur am Schreibtisch mit einer Docking-Unit. Insofern werden die Datenmengen größer und letztlich funktioniert dies nur, wenn die Access Points steuernd und regelnd eingreifen. Laut Ubiquiti sollen dabei drei Funktionen die Situation verbessern:

 

Insbesondere die Funktion "Airtime Fairness" wird auch von anderen Herstellern so genannt, bei der ein Client erst senden darf, wenn der AP dies zulässt. Das ist eine wichtige Funktion damit zwei Clients sich nicht stören, wenn beide noch mit dem AP sprechen können aber sie direkt nicht mehr "hören" und damit nicht erkennen können, wenn die anderen Teilnehmer senden. Dann schaltet der AP auf einen RTS/CTS-Mode um und vergibt Sendeberechtigungen. Hier hat der AP dann auch einen Hebel die Verteilung der Slots nicht nach "Paket" sondern nach Datenmenge und empfangsstärke zu steuern. So kann nicht nur eine VOIP Verbindung arbeiten sondern ein entfernter und damit auch langsamer Client bremst nicht mehr einen näheren schnellen Client aus.

AirTime Fairness ist heute eigentlich zwingend, damit jeder Client anstatt der gleichen Paketanzahl den gleichen "Zeitanteil" bekommt. So können die schnellen Geräte in ihrem Zeitslot viel mehr Daten übertragen und langsame Geräte bremsen die modernen Geräte, zu denen meist auch die aktuellen Notebooks nicht so stark aus. VoIP bleibt möglich aber die Obergrenzen der Bandbreite abhängig vom Standort können natürlich nicht wegdiskutiert werden.
Siehe dazu auch VoIP mit WiFi und QoS WiFi

Erfahrungen

Ich kannte vorher meinen Hardware-Zoo aus Fritz!Box 7490 im Keller, deren WiFi Leistung natürlich nie im Haus angekommen ist, einem Edimax-Device mit abgeschalteten DSL, ungenutzten USB-Anschluss und 4-Port Switch als "Dual-Band Accesspoint" und einem billigen 25€ Accesspoint (2,4GHz mit 4port 10/100 Switch) im OG. Eine Zeit lang habe ich verschiedene SSIDs genutzt, um mal zu sehen an welchem AP ich nun angeschlossen und wie gut die Verbindung war. Handover haben aber eher schlecht geklappt und oft ist der Client am alten entfernten AP verblieben statt sich zum aktuellen zu verbinden. Richtig "gesehen" habe ich aber nicht, was die Clients gemacht haben und wie gut deren Empfang war.

In Firmen sehe ich die für Privatpersonen unbezahlbaren Cisco-Systeme. Mit Ubiquiti habe ich ein System gefunden, was mit den zusätzlichen Gateway und Switches im Enterprise-Umfeld agiert aber durch die Installation per App und autarke Funktion auch für Heimbüros interessant ist. Etwas leistungsfähiger wird so ein System, mit der bei Bedarf gestarteten Management-Software, mit der schon zwei Access-Points Spaß machen aber auch problemlos Firmen ihre Gebäude und Standorte versorgen können.

Aktuell habe ich gerade mal einen AP AC Pro zentral verbaut und auf einem Server die Management-Software installiert. Dank der Mobilfunk-App kann ich von überall einen Bandbreitentest gegen den AP machen und so sehr elegant die Ausleuchtung kontrollieren. Wer nicht das letzte Quäntchen Performance abrufen muss, ist aber mit dem AP AC Lite für unter 85€ auch sehr gut bedient.

Ubiquiti Switches

Vom gleichen Hersteller gibt es auch verschiedene Switches. Sowohl eine "Edge-Serie" mit klassischem Monitoring, SNMP etc. und auch die Ubiquiti-Switches, die mit der UNifi-Software einfach mit verwaltet werden. Ich habe noch keinen solchen Switch und mein PRTG TL-SG1024DE wurde schon durch einen  TPLink T2600G-28TS ersetzt. Aber es gibt auch für diese Switches schon Skripte um diese in PRTG zu integrieren

Weitere Links