Posts Tagged ‘UniFi’

Sonntag, 8. Juli 2018

UniFi Produktenamen in syslog-Nachrichten

Auf meiner ELK-Installation finden sich unter anderem auch die Logs meiner UniFi-Controller und der damit kontrollierten Access Points. In den syslog-Nachrichten werden die Typen von UniFi-Netzwerkgeräten mit folgenden Kürzeln identifiziert:

  • U7PG2 — UniFi AP-AC-Pro Gen2
  • U7MSH — UniFi AP-AC-Mesh
  • U7LR — UniFi AP-AC-LR
  • U7P — UniFi AP-Pro

Die offizielle Liste von UniFi findet sich im JSON-Format hier: bundles.json.txt

Tags: , , , , ,
Labels: IT

Keine Kommentare | neuen Kommentar verfassen

Sonntag, 10. Juni 2018

Init7 TV7: Turris Omnia, UniFi Switch, Multicast und IGMP Snooping

Seit der Ankündigung von Init7 verwende ich gelegentlich deren TV7-Angebot, welches ein ganz „normales“ Multicast IPTV ist.

Bei der Konfiguration des Services bei einer Bekannten, welche ich mit einem Ubiquiti EdgeRouter ER-X ausgestattet habe, musste ich feststellen, dass das Netzwerk wie vom ISP angedroht mit Multicast geflutet wird, wenn man einen TV-Sender schaut.

Das spürt man sehr gut, wenn man über den am ER-X angeschlossenen Ubiquiti UniFi AP-AC-LR surfen will oder bspw. eine SSH-Verbindung aufgebaut hat. Zwischen dem Druck einer Taste und dem erscheinen des Buchstabens in der Shell gibt es eine spürbare Verzögerung.

Damals war ich der Meinung, dass mein Turris Omnia hier zu Hause mit IPTV Multicast zu schlage kommt, weil ich solche Probleme initial nicht wahrnahm. Doch auch mein Netzwerk wird in Mitleidenschaft gezogen, und auch hier spüre ich es primär mittels Verbindungsproblemen mit dem UniFi Access Point. Da ich direkt nach dem Turris Omnia einen UniFi Switch US-8-60W angeschlossen habe und die Interface-Statistiken mit Cacti aufzeichne, kann ich das Problem einfach visualisieren — an Hand des Matches der Schweizer Nationalmannschaft gegen Japan am Freitag, 8. Juni 2018 ab 19 Uhr (wir schalteten uns ein paar Minuten später zu):

image-7929

Man sieht auf den Graphen sehr gut, dass Multicast auf allen Interfaces des Switches einschlägt, egal, ob das Netzwerkgerät dahinter den Stream schaut oder nicht.

Was ich jetzt zudem auch noch realisiere: Meine Sonos PLAYBASAE, der SUB und die beiden Sonos PLAY:1 hatten Probleme mit der Audio-Wiedergabe von IPTV-Streams. Ich dachte, dass dies entweder an den Streams selber oder aber den Apps liegt, welche ich verwendet habe. Mir schwant nun aber, dass die PLAYBASE das Audio auf Grund des Multicast-Floodings eifach nicht schnell genug über den UniFi Access Point (d.h. per WLAN) zum SUB und den zwei PLAY:1 senden konnte.

Der Match lief bei uns über die App iPlayTV auf dem Apple TV 4 (mit Ethernet am UniFi-Switch angeschlossen) via HDMI auf unserem Panasonic Plasma in der Stube. Hierzu verwende ich udpxy, welches auf einem Linux-Server Intel NUC läuft, welcher ebenfalls am UniFi-Switch angeschlossen (dies nicht aus Spass; iPlayTV kommt mit der M3U8 respektive dem Multicast-Stream direkt von TV7 irgendwie nicht klar). D.h. udpxy empfängt Multicast, wandelt es in einen Unicast-Stream um und sendet diesen an den Apple TV.

Mitten im Spiel entschied ich mich, den Apple TV direkt an einen der vier freien Switch-Ports des Turris Omnia zu hängen (jetzt, als ich diese Zeilen schreibe, realisiere ich gerade, dass ich eigentlich den NUC dort hätte anhängen sollen, da er ja der Multicast-Empfänger war — und nicht den Apple TV). Das änderte an der Multicast-Flut nichts (wie auch, der Multicast-Empfänger war immer noch am Switch angehängt — ich Depp!).

Der Turris Omnia aber hat gemäss Kommandozeile IGMP-Snooping aktiviert:

$ cat /sys/devices/virtual/net/br-lan/bridge/multicast_snooping
1

Quellen: How can I enable IGMP Snooping in OpenWRT? sowie IPTV / UDP multicast

Schlussendlich nach viel Googlen dann die Erkenntnis: Ich musste IGMP Snooping noch auf meiner Ubiquiti-Netzwerkinfrastruktur aktivieren! Das macht man über den UniFi-Controller:

  1. Login auf die Web-Oberfläche des UniFi-Controllers
  2. Settings
  3. Networks
  4. Edit
  5. [x] Enable IGMP Snooping

image-7930

Et voilà! Auf den Cacti-Graphen sind man in der Detail-Ansicht sehr schön, dass ich um spätestens 20:45 Uhr IGMP Snooping auf dem Switch aktiviert hatte:

image-7931

Der Multicast-Stream mit locker 15 Mbit/s kommt immer noch über den Router auf dem Switch rein (Port 1, mit „TURRIS OMNIA“ bezeichnet), doch er wird nur noch an Switch-Port 3 weitergereicht, an welchem der NUC hängt, auf welchem udpxy läuft und den Multicast-Stream in Unicast umwandelt. Die anderen Ports werden mit Multicast sinnvollerweise nicht mehr bedient, und deshalb bricht die blaue Linie (Outbound-Traffic, d.h. in Richtung des angeschlossenen Netzwerkgerätes) fast gegen Null ein.

Was ich jetzt noch mache: Ich hänge den NUC auch noch direkt an einen freien Ethernet-Port des Turris Omnia. Dann gibt es eigentlich keinen Grund mehr, wieso Multicast-Traffic überhaupt bis zum UniFi-Switch gelangen sollte (ausser ich streame diesen bspw. auf meinem per Ethernet angebundenen iMac im Büro).

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

1 Kommentar | neuen Kommentar verfassen

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

7 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