Posts Tagged ‘UniFi’

Donnerstag, 22. März 2018

Wenn der UniFi Controller die MongoDB Log-Datei gigabyteweise füllt

Ich betreibe an drei physischen Standorten auf zu Linux-Servern umfunktionierten Lenovo-Laptops je einen UniFi-Controller, um die UniFi-Access Points an diesen drei Standorten zu provisionieren und zu überwachen.

Wer diese Software ebenfalls im Einsatz hat, sollte insbesondere nach Updates gelegentlich mal in das Verzeichnis /var/log/unifi reinschauen und überprüfen, dass sich die Log-Datei mongod.log nicht im Sekundentakt mit nachfolgend aufgeführten Fehlermeldungen füllt und so locker mehrer Gigabyte gross werden kann:

2018-03-12T20:49:21.010+0100 I CONTROL  [main] ***** SERVER RESTARTED *****
2018-03-12T20:49:21.018+0100 I CONTROL  [initandlisten] MongoDB starting : pid=26817 port=27117 dbpath=/usr/lib/unifi/data/db 64-bit host=HOSTNAME
2018-03-12T20:49:21.018+0100 I CONTROL  [initandlisten] db version v3.2.11
2018-03-12T20:49:21.018+0100 I CONTROL  [initandlisten] git version: 009580ad490190ba33d1c6253ebd8d91808923e4
2018-03-12T20:49:21.018+0100 I CONTROL  [initandlisten] OpenSSL version: OpenSSL 1.0.2l  25 May 2017
2018-03-12T20:49:21.018+0100 I CONTROL  [initandlisten] allocator: tcmalloc
2018-03-12T20:49:21.018+0100 I CONTROL  [initandlisten] modules: none
2018-03-12T20:49:21.018+0100 I CONTROL  [initandlisten] build environment:
2018-03-12T20:49:21.018+0100 I CONTROL  [initandlisten]     distarch: x86_64
2018-03-12T20:49:21.018+0100 I CONTROL  [initandlisten]     target_arch: x86_64
2018-03-12T20:49:21.018+0100 I CONTROL  [initandlisten] options: { net: { bindIp: "127.0.0.1", http: { enabled: false }, port: 27117, unixDomainSocket: { pathPrefix: "/usr/lib/unifi/run" } }, storage: { dbPath: "/usr/lib/unifi/data/db" }, systemLog: { destination: "file", logAppend: true, path: "/usr/lib/unifi/logs/mongod.log" } }
2018-03-12T20:49:21.068+0100 E NETWORK  [initandlisten] listen(): bind() failed errno:98 Address already in use for socket: 127.0.0.1:27117
2018-03-12T20:49:21.069+0100 E NETWORK  [initandlisten]   addr already in use
2018-03-12T20:49:21.069+0100 E STORAGE  [initandlisten] Failed to set up sockets during startup.
2018-03-12T20:49:21.069+0100 I CONTROL  [initandlisten] dbexit:  rc: 48

Relevant ist die eine Zeile, die da lautet:

2018-03-12T20:49:21.068+0100 E NETWORK  [initandlisten] listen(): bind() failed errno:98 Address already in use for socket: 127.0.0.1:27117

Sie besagt, dass bereits ein Prozess auf Port 27117 lauscht. Und was macht das blöde Stück Software in einem solchen Fall? Es startet neu, immer wieder, ohne Ende. Und bei jedem Neustart (gefühlt alle Sekunde, wenn man sich mit tail -f dranhänkt) füllt sich das Log mit weiteren 1600+ Bytes und somit mit 5.6 Megabytes pro Stunde, 134.4 MB pro Tag und 940.8 MB pro Woche.

Als Anschauungsbeispiel das Log-Verzeichnis auf einem meiner Server:

/var/log/unifi]# ls -lh
total 1.2G
-rw------- 1 unifi root     0 Mar 18 00:08 mongod.log
-rw------- 1 unifi root   153 Jan 12 14:32 mongod.log.10.gz
-rw------- 1 unifi root   900 Jan  5 23:38 mongod.log.11.gz
-rw------- 1 unifi root   882 Dec 30 22:15 mongod.log.12.gz
-rw------- 1 unifi root   687 Dec 23 02:27 mongod.log.13.gz
-rw------- 1 unifi root   691 Dec 16 10:58 mongod.log.14.gz
-rw------- 1 unifi root  1.1G Dec  2 12:07 mongod.log.15.gz
-rw------- 1 unifi root  3.4M Mar 13 21:30 mongod.log.1.gz
-rw------- 1 unifi root   30M Mar 12 00:09 mongod.log.2.gz
-rw------- 1 unifi root   23M Mar  4 00:09 mongod.log.3.gz
-rw------- 1 unifi root   30M Feb 26 00:07 mongod.log.4.gz
-rw------- 1 unifi root   23M Feb 18 00:09 mongod.log.5.gz
-rw------- 1 unifi root   30M Feb 12 00:08 mongod.log.6.gz
-rw------- 1 unifi root  1.7M Feb  4 00:10 mongod.log.7.gz
-rw------- 1 unifi root   675 Jan 26 09:19 mongod.log.8.gz
-rw------- 1 unifi root   236 Jan 21 14:25 mongod.log.9.gz

Wie man auf einen Blick sieht, hat sich das Log in der Woche vom 25. November bis zum 2. Dezember auf diese Weise gefüllt und war selbst mit gzip gezippt noch satte 1.1GB gross. Im Vergleich zu anderen Wochen, wo ein paar wenige Bytes zusammenkommen.

Wer den UniFi-Controller auf einer SSD-Platte laufen hat, dem werden ob diesen Schreiboperationen die Tränen kommen.

Was ist die Lösung?

# killall mongod

Startet der UniFi-Controller die MongoDB das nächste Mal neu, kann sie sich an den Port binden.

In den Foren des Herstellers finden sich auf Anhieb eine einzige Meldungen zum Symptom, aber mit einem anderen Lösungsvorschlag, der mit meiner Situation nichts zu tun hatte:

Auf Ask Ubuntu findet sich eine generelle Problemmeldung zum Thema MongoDB: Mongod server not woking due to the following error. Von hier stammt schlussendlich der essentielle Hinweis, einfach den bereits laufenden mongodb-Prozess zu „killen“.

Tags: , , ,
Labels: Linux

2 Kommentare | neuen Kommentar verfassen

Samstag, 10. Februar 2018

UniFi AC Mesh AP als Bridge nutzen

Die Web-Site und Online-Shops sind in dem Punkt nicht explizit respektive klar, doch ich kann bestätigen, dass man einen UniFi AC Mesh AP einerseits per WLAN mit einem bestehenden UniFi Access Point verbinden und so die Reichweite des originalen Access Points steigern kann, aber andererseits (gleichzeitig) auch ein Netzwerkkabel vom Mesh Access Point zu einem PC ziehen und diesen PC mit einem Netzwerkzugang ausstatten kann.

Aus Sicht des PCs befindet er sich im lokalen Ethernet-Netzwerk; die Pakete werden per WLAN vom Mesh Access Point zum originalen Access Point übertragen und gelangen von dort zu anderen Geräten im Intranet respektive ins Internet.

Ich gehe davon aus, dass man anstelle eines PCs auch einen Switch an den Ethernet-Eingang eines Mesh Access Points hängen und so mehrere Geräte respektive ein ganzes isoliertes LAN mit dem Original-LAN bridgen kann, versucht habe ich das im Gegensatz zum alleinstehenden PC nicht.

Tags: , , ,
Labels: IT

5 Kommentare | neuen Kommentar verfassen

Samstag, 10. Februar 2018

UniFi Controller erkennt einen Repeater als Rogue Access Point

Im letzten Jahr hat ein Bekannter von mir in seinem Haus eine neue Wärmepumpe der Firma Waterkotte installiert, welche Wärme aus einer Quellwasserleitung extrahiert, die das Grundstück durchquert.

Die Wärmepumpe verfügt zeitgemäss auch über einen eingebauten Industrie-Computer (PCEngines APU2C2) mit Netzwerkanschluss, auf welchem ein Web-Server läuft. Darüber lassen sich nicht nur die Vitaldaten des Geräts abfragen, sondern dieses auch steuern.

Wie es aber in älteren Gebäuden so ist, hat im Boilerraum natürlich niemand einen Netzwerkanschluss installiert und auch keine Netzwerkkabel hingezogen. Wie bringt man das Gerät somit ins lokale Netzwerk?

Der lokale Lieferant hatte die Lösung: Der Industrie-PC ist mit einem Ethernet-Kabel an einen D-Link DIR-809 angeschlossen. Der Access Point wiederum ist per WLAN mit dem UniFi Access Point der Wohnung im oberen Stockwerk verbunden. Dies, indem der D-Link Access Point in den Repeater-Modus geschaltet wurde und die WLAN-Zugangsdaten statisch einprogrammiert wurden.

Der Bekannte klagte in der Folge aber über instabile Netzwerkverbindungen — mal war die Wärmepumpe erreichbar, aber oftmals nicht. Nach einigem Debugging dann die Erkenntnis: Der UniFi-Controller im LAN erkennt den Repeater nicht als „normalen“ Client, sondern als Rogue Access Point, d.h. als ein Access Point, der vorgibt, ein anderer Access Point zu sein.

Hat man bei einer ähnlichen Installation dieselbe Vermutung, überprüft man das in der Web-Oberfläche des UniFi-Controllers. Einerseits warnt einem der Controller sowohl in der Oberfläche (Nachrichten-Pop-Up) als auch per E-Mail über Rogue Access Points, die in der Empfangsreichweite von UniFi Access Points mit derselben SSID funken …

image-7663

… andererseits werden solche Geräte in der Rubrik „Insights“ auch markant mit einem roten Punkt in der Spalte „Rogue“ dargestellt:

image-7664

Das Problem ist in dem Fall, dass Rogue Access Points vom UniFi Controller automatisch geblockt werden. Dies führte zum Symptom mit den Verbindungsabbrüchen.

Ich habe dann die Funktion benutzt, Rogue Access Points als bekannt zu markieren und den D-Link whitegelistet. Die UniFi-Firmware besitzt diese Funktion offenbar seit Version 5.5.19.

Leider half das aber auch nur temporär; der D-Link Access Point wurde regelmässig wieder als Rogue Access Point klassifiziert und geblockt.

Schlussendlich entschied ich mich dazu, den D-Link Access Point dem Installateur zurückzugeben, (damals) 120 CHF zu investieren und einen UniFi AC Mesh AP im Boilerraum zu installieren.

Am Netzwerkanschluss des Mesh Access Points hängt neben dem PoE-Injektor der Industrie-PC und der Mesh Access Point verbindet sich nun seit Monaten reibungslos mit dem UniFi AP AC Pro.

Keine Unterbrüche, keine Sorgen — mitsamt dem Vorteil, dass im Untergeschoss nun besserer WLAN-Empfang herrscht.

Tags: , , , , , , ,
Labels: IT

Keine Kommentare | neuen Kommentar verfassen

Samstag, 10. Februar 2018

An welchem Port eines UniFi Switches hängt ein Netzwerkgerät?

Hierzu öffnet man die Web-Oberfläche des UniFi-Controllers, wählt „Clients“ an, sucht das Netzwerkgerät in der Liste und klickt es an. In den Detailinfos am rechten Browserrand steht unter „Overview“ nicht nur, dass das Gerät am Switch angeschlossen ist, sondern auch an welchem Port: #Portnummer. Im nachfolgenden Beispiel hängt mein Apple TV an einem Netzwerkkabel, welches an Port 5 meines Switches eingestöpselt ist:

image-7654

Tags: , , , , , , ,
Labels: IT

Keine Kommentare | neuen Kommentar verfassen

Freitag, 20. Oktober 2017

Ubiquiti hat seine Produkte gegen KRACK bereits gepatcht

More to the point, measure your current vendors by how long it takes them to patch. Throw away gear by those vendors that took a long time to patch and replace it with vendors that took a short time.

Quelle: Some notes on the KRACK attack

Im Januar 2016 habe ich meinen ersten Ubiquiti UniFi-Access Point gekauft und bin seither hell begeistert von den Produkten — bei mir kommt nur noch UniFi ins Haus, wenn es um die Versorgung eines Gebäudes mit WLAN geht. Mittlerweile habe ich solche Access Points an drei Standorten ausgerollt.

Als die Kunde von KRACK an die Öffentlichkeit gelangte, hatte ich die Hoffnung, dass Ubiquiti äusserst rasch reagieren würde.

Und das taten sie auch: Innert 24 Stunden standen aktualisierte Firmware-Dateien für die gesamte Produktepalette zum Download und zur manuellen Installation bereit.

Als ich mich heute auf den Controllern an den drei Standorten einloggte dann die frohe Botschaft im GUI des Controllers: Für alle meine Access Points stand Firmware 3.9.3.7537 zur automatisierten Installation bereit.

Das Bauchgefühl hat sich somit als richtig erwiesen: Der Hersteller baut nicht nur tolle Produkte, die man nie mehr hergeben möchte, sondern nimmt auch die Sicherheit seiner Software ernst und aktualisiert diese schnurstracks. Nach knapp zwei Minuten war das Upgrade vorüber und die Access Point frisch gegen KRACK gesichert.

Ubiquiti erhält das Sicherheits-Gütesiegel von mir. Wer es noch nicht getan hat: Kaufen!

Tags: , , , , ,
Labels: IT

Keine Kommentare | neuen Kommentar verfassen

Samstag, 6. Mai 2017

Einen UniFi Access Point forcieren, die Konfiguration neu einzulesen

Heute habe ich einen weiteren UniFi Access Point (dieses Mal wieder einen AC AP PRO) in Betrieb genommen.

Leider konnte ich den Access Point nach einigen Stunden Betrieb nicht dazu bewegen, die gemäss meiner Anleitung aktualisierten SSH-Keys neu einzulesen. Im Fachjargon nennt man das „forced re-provisioning“.

Ein Neustart des Access Points über das Web-Interface des UniFi-Controllers bewirkte nichts.

Schlussendlich entdeckte ich mehrere Threads in den Foren des Herstellers (Ubiquiti) und musste realisieren, dass der Hersteller offenbar keine direkte Möglichkeit implementiert hat, um einen Access Point mitzuteilen, seine Konfiguration vom Server neu einzulesen.

Everytime you change something at a config.properties, the APs need to be reprovisioned to apply that configurations. A reboot on the controller or the APs will not trigger a reprovision. So you have two options:
1) If you want to reprovision a single or a few APs, you can manually change one of their settings, like channel or TX power, then revert the config. Only that APs will be reprovisioned and will then apply whatever you have at config.properties for that site.
2) To reprovision all APs on a site you can enable and then disable the guest portal. This will trigger a reprovision on all APs, and apply all the settings on config.properties for that site.

Quelle:

Folgende Massnahme hat dann aber zum gewünschten Erfolg geführt:

  1. UniFi Controller
  2. Devices
  3. Klick auf den Namen des gewünschten Access Points
  4. In der rechten Spalte erscheinen die Eigenschaften des Access Points
  5. Configuration
  6. Radios
  7. Channel Width: Einen anderen Wert auswählen, als derzeit aktiviert (bei mir von HT40 zu HT20)
  8. Queue Changes

Nach einigen Sekunden sollte die Konfiguration endlich neu eingelesen worden sein. Nun die Änderungen rückgängig machen — und fertig.

Tags: , , , , , ,
Labels: IT

Keine Kommentare | neuen Kommentar verfassen

Montag, 20. März 2017

UniFi Controller erkennen automatisch unerlaubte WiFi Access Points

Als ich gestern mit meinem TP-LINK TL-MR3020 am herumspielen war, tauchte plötzlich folgende E-Mail-Nachricht in meiner INBOX auf:

image-7226

Ein Feature, von dem ich nicht wusste, dass es existiert. Nett. Umkehrschluss: Da der UniFi Controller das erste Mal ausgeschlagen hat, hatte ich noch nie einen „Rogue Access Point“ im Netz.

PS: Und ja, bevor jemand fragt: Die Konfigurationsoption für den Domain-Namen des Systems habe ich mittlerweile auch entdeckt und der Realität angepasst …

Tags: , , , , , , , ,
Labels: IT

Keine Kommentare | neuen Kommentar verfassen

Mittwoch, 18. Januar 2017

Wenn Laien Entwicklunsgzeiten schätzen …

Wenn der Vollprofi sagt, dass die Entwicklung eines Features mit einer externen Schnittstelle 10 Personentage in Anspruch nimmt, muss es ja wohl stimmen …

SMS password for Guest Portal
Is a great idea , fast release this!
I think new guest authentication perfect , and give up sales unifi in the air!
Its a week job and week test … realy need unifi wifi.

by worksart
on ‎09-15-2015 12:38 AM

Quelle: SMS password for Guest Portal

Tags: , , , ,
Labels: Funny, IT

Keine Kommentare | neuen Kommentar verfassen

Sonntag, 13. November 2016

UniFi Access Points mittels IKEA-Hack in der Wohnung platzieren

Zur selben Zeit, als ich Brandmelder angeschafft habe und mir am Überlegen war, wie man diese Sensoren ohne Beschädigung der Decken in der Wohnung platzieren kann, habe ich mir auch zwei UniFi Access Point angeschafft.

Der IKEA-Hack mit den Variera Tellerhaltern für die Montage der Brandmelder liess sich 1:1 auch auf die Access Points übertragen, da IKEA Tellerhalter in zwei Grössen im Angebot führt (die UniFis hätten rein vom Durchmesser überhaupt nicht in die Brandmelder-Halterung gepasst). Für UniFi Access Points eignet sich das grössere der beiden Modelle, das Teller in der Grösse von 19cm bis 32cm aufnimmt:

VARIERA Tellerhalter, Buche hell, Edelstahl (IKEA Artikelnummer 802.404.16; 9.95 CHF)

Wieso dieser Aufwand? UniFi Access Points senden ihre Signale in Form eines „Donuts“ aus, wenn der Access Point horizontal aufliegt. Der „Donut“ ist aus der horizontalen Sicht aber nicht symmetrisch: Auf der Deckenseite des Access Point mit der Zuführung des Ethernet-Kabels ist die Abstrahlung weniger wulstig als auf der Luftseite (dort, wo das Logo prangt und die blaue LED leuchtet):

unifi-access-point-donut-horizontal
image-7049

NACHTRAG: Unter Antenna radiation pattern for UniFi AP (diagramm inside) habe ich weitere Diagramme gefunden:

unifi-horizontal-polarization-mounted-wall
image-7050

unifi-horizontal-polarization-mounted-roof
image-7051

unifi-vertical-polarization-mounted-wall
image-7052

unifi-vertical-polarization-mounted-roof
image-7053

Quelle: [Ervaringen/discussie] Ubiquiti-apparatuur

Dies ist einfach erklärbar: Die Macher der semi-professionellen Access Points gehen davon aus, dass die Dinger in der Regel an Decken montiert werden. Richtung Decke selber bringt eine WiFi-Durchdringung niemandem etwas, aber von der Decke weg (Richtung Zimmerboden) muss eine möglichst grosse Abdeckung erreicht werden.

Aus diesem Grund habe ich beide Access Points auf dem Tellerhalter montiert und in der Stube sowie im Büro möglichst an hoher Position aufgestellt. Das sieht dann so aus:

UniFi Access Point IKEA Variera Mount Living Room
image-7054

Tags: , , , , , , , , , ,
Labels: IT

3 Kommentare | neuen Kommentar verfassen

Sonntag, 17. April 2016

Den eigenen SSH Public Key auf einem UniFi Access Point hinterlegen

Um sich ohne Passwort auf einen UniFi Access Point einzuloggen, ist der SSH Public Key auf dem Access Point in folgender Datei zu hinterlegen:

Persistent

Folgende Anpassungen überlebt Reboots des Access Points und ist dementsprechend die einzig zuverlässige Variante ohne böse Überraschungen.

Auf dem Server, der als UniFi-Controller dient, legt man eine Datei namens config.properties an, die folgende Zeilen enthält:

config.system_cfg.1=sshd.auth.key.1.status=enabled
config.system_cfg.2=sshd.auth.key.1.value=AAA...== Beschreibung des Public Keys 1
config.system_cfg.3=sshd.auth.key.1.type=ssh-rsa

config.system_cfg.4=sshd.auth.key.2.status=enabled
config.system_cfg.5=sshd.auth.key.2.value=AAA...== Beschreibung des Public Keys 2
config.system_cfg.6=sshd.auth.key.2.type=ssh-rsa

config.system_cfg.7=sshd.auth.key.3.status=enabled
config.system_cfg.8=sshd.auth.key.3.value=AAA...== Beschreibung des Public Keys 3
config.system_cfg.9=sshd.auth.key.3.type=ssh-rsa

config.system_cfg.10=sshd.auth.key.4.status=enabled
config.system_cfg.11=sshd.auth.key.4.value=AAA...== Beschreibung des Public Keys 4
config.system_cfg.12=sshd.auth.key.4.type=ssh-rsa

Im obigen Beispiel konfiguriere ich insgesamt vier Public Keys (sshd.auth.key.1 bis sshd.auth.key.4). Wer nur einen Schlüssel hinterlegen muss, pflegt dementsprechend nur die ersten drei Zeilen in die Datei ein.

Dem Wert sshd.auth.key.1.value weist man den ganzen Public Key zu, ohne aber den Typ (bei mir ssh-rsa) zu erwähnen. Auch Anführungszeichen sind nicht nötig, wenn dem Public Key noch eine Beschreibung mit Leerschlägen folgt (ist bei mir der Fall).

Der Pfad zu dieser Datei hängt vom Betriebssystem und den im Controller definierten Site-Namen ab. Bei mir (Debian GNU/Linux, Site-Name „default“) lautet der Pfad /var/lib/unifi/sites/default/config.properties.

Die Inspiration für dieses Prozedere habe ich dem Artikel UniFi – Add Custom SSH Keys to Your UniFi Devices entnommen.

Den Site-Namen findet man mit folgender Anleitung heraus: UniFi – config.properties File Explanation. Weitere Optionen (bspw. Public Keys, die nur auf einzelne Access Points ausgerollt werden) findet man im Artikel UniFi – How to make persistent changes to UAP(s) system.cfg.

Nicht persistent

Folgende, je nach Firmware unterschiedliche Methoden, erlauben ebenfalls den passwortlosen Login. Nach dem nächsten Neustart des Access Points müssen die Schritte aber zwingend wiederholt werden — die Anpassungen sind nicht persistent.

Firmware 3.4.19

/etc/persistent/.ssh/authorized_keys

Via: ssh key based auth

Wie ich im Januar 2017 bemerken musste, konnte ich mich so nicht mehr mit meinen SSH-Schlüsseln auf die UniFi Access Points einloggen. Nach einer Stunde debuggen dann endlich die Erkenntnis:

Firmware 3.7.28.5442

/etc/dropbear/authorized_keys

Evtl. ist auch noch folgender Befehl nötig (das merke ich spätestens beim nächsten Reboot):

# cfgmtd -w -p /etc

Quelle: Unifi AP: Maintaining SSH access whilst disabling password logins (authorized_keys only) sowie Hacking the KanKun Smartplug – HowTo: Login to SSH on BusyBox (DropBear) Without a Password

Tags: , , ,
Labels: Linux

Keine Kommentare | neuen Kommentar verfassen