Beiträge von white_rabbit

Der Controller läuft auf einem aktuellen Debian. Vorher lief er mal auf einem Ubuntu, doch irgendwann hatte ich die Config gesichert und neu einspielt. Das gab keinerlei Probleme ... wir machen die Updates übrigens mit dem EUS. Das lief immer glatt.

(Mit "seltsame Effekte im WLAN" meine ich übrigens Dinge wie "Roaming klappt nicht immer"; oder: wenn man durch das Gebäude läuft, kann man sich manchmal nur verzögert mit einem AppleTV verbinden o.ä. Ist schon klar, dass es da sehr vielfältige Ursachen geben kann aber wenn das hier einer der Gründe sein kann, wäre vielleicht die Nadel im Heuhaufen gefunden!?!?)

Bleibt die Frage, ob es dazu zu Problemen kommen kann ... wir haben hier manchmal schon ein paar merkwürdige Effekte (es gibt allerdings auch sehr viele Geräte im WLAN). Wenn das also daran liegen kann, weil z.B. Pakete mal über die tagged und mal über die untagged Leitung gehen (falls das denkbar ist), wäre ich weiterhin an einer Lösung interessiert. Kann ja auch sein, dass es einfach nur falsch im WebUI angezeigt wird und so gar nicht auf dem Port landet...

Nein, das Löschen klappt weder im alten noch im neuen WebUI.

Ich habe gesehen, dass es mittlerweile unter Ports -> VLANs auch eine Übersicht gibt, die nochmal genau das anzeigt, was hier so merkwürdig ist:

Da sieht man's auch nochmal: VLAN.1 ist untagged (blau) auf allen Ports -- aber eben scheinbar auch nochmal zusätzlich (geht das überhaupt??) tagged mit auf der Leitung.

Ich finde das höchst merkwürdig und habe wirklich keine Erklärung, wie es dazu kam (außer das oben genannte Einspielen der Config vielleicht...??!)

Klar -- die anderen VLANs laufen ganz normal aber die ID.1 wurde (nicht durch mich sondern durch irgendeine Aktion?!) automatisch mehrfach eingerichtet. Vielleicht kam das mit dem Umzug des Controllers auf andere Hardware, als ich die Konfiguration eingespielt habe? Ich kann das aber nicht entfernen und weiß auch nicht, warum es überhaupt mehrfach angelegt werden kann. Aber das sieht definitv falsch aus.

Kann man evtl manuell direkt in die Config gehen und die fehlerhaften Einträge löschen?

Bei uns ist es so, dass VLAN.1 untagged auf der Leitung liegt und die anderen tagged dazu kommen...

Hallo.

Ich habe in unserem Unifi-Controller alle VLANs, die wir benötigen angelegt. Aus irgendeinem merkwürdigen Grund, taucht allerdings das VLAN1 gleich drei Mal auf und lässt sich auch nicht löschen. Hat jemand eine gute Erklärung?
Im Controller sieht das dann so aus:

Ich weiß nciht, wodurch das geschehen ist aber es sieht jedenfalls falsch aus...?!

Ja, die Ansicht gibt's -- das ist schon klar! Aber das alte Interface zeigt weitaus mehr Meldungen an als das neue!

Im neuen Interface tauchen ganz viele Meldungen (zumindest hier!) gar nicht mehr auf. Daher (auch) das ständige zurückschalten auf das alte Interface...

Also ich wechsel (notgedrungen) auch täglich zwischen beiden Ansichten ... in der Legacy Ansicht werden auch mehr Dinge protokolliert ... da sehe ich z.B. disconnects von Geräten, die im neuen Interface gar nicht auftauchen.

Also ich bin mit der neuen Version des Controllers auch nicht zufrieden ... der läuft nicht mehr glatt.

Wir hatten heute mehrfache Aussetzer von zwei Swtiches, was zuvor so nicht vorkam.

Dass nun die Widgets fehlen, kann ich ja auch noch verkraften aber es ist einfach großer Murks, dass man dauernd zwischen dem alten und dem neuen Interface hin- und herschalten muss, weil es

a.) noch Optionen gibt, die im alten Interface aktiv sind aber im neuen noch gar nicht gezeigt werden oder

b.) Optionen nur im neuen Interface vorhanden sind und die im alten Interface gar nicht (de-)aktiviert werden können.

Unter'm Strich also die Frage: Wann ist die Version 7 soweit fertig, dass man ALLES unter der neuen Oberfläche bedienen kann?

Davon unabhängig könnten die Beobachtungen von heute evtl wirklich mit dem Update auf Java-11 zusammenhängen??!

Gateway ist eine OPNSense -- kein Unifi. Ich bin auch nicht sicher, ob eine UDM-(Pro) o.ä. so viele Clients stemmen könnte ... in den Beschreibungen liest man immer was von ca 200 Clients ... hier sind es aber mehr als 1000.

Aber in der Version 7.2 stand über dieser Ansicht immerhin noch "most active clients" usw ... selbst *diese* Widgets sind jetzt verschwunden???

Hallo.

Ich habe heute ein Upgrade auf die Controller Version 7.3.76 gemacht .... und bin relativ enttäuscht. Zum einen war der Controller eine Zeit lang gar nicht erreichbar (wie man im folgenden Screenshot sieht) und zum anderen ist das Dashboard jetzt noch weiter zusammengeschrumpft und zeigt keine weiteren Widgets mehr bis auf die Anzahl der Verbindungen. Wenn man das Dashboard lädt, erhält man ja so eine graue Ansicht, die zeigt, dass da *eigentlich* auch andere Widgets möglich sein sollten ... aber: WO stellt man das ein?

(Ich habe den Controller mit dem EUS von Glenn.R. aufgesetzt und führe auch jedes Update damit durch.)

Hier mal ein Screenshot, damit man sich's besser vorstellen kann, was ich meine:

Ich weiß nicht, ob wir von den selben Backups sprechen -- es ist jedenfalls so, dass der Controller alle paar Minuten einen der APs als "getrennt" meldet. Und in der gleichen Minute ist er dann auch schon wieder da. Die Tipps von der oben genannten Seite habe ich ohne irgendeine Änderung festgestellt zu haben, umgesetzt. Daran lag es nicht. Der Controller ist in dem VLAN für alle APs erreichbar ... auch auf allen Ports ... es muss also noch etwas anderes sein.

Ach ja: Firmware und Controller sind beide auf dem aktuellen Stand (s.o.)

Hallo.

Also die Controller-IP lautet 192.168.1.100 -- und die inform-URL dazu passenderweise wie oben

http://192.168.1.100:8080/inform

Ich denke mal, dass das passt, denn sonst könnte ich ja auch gar keine neuen Accesspoints provisionieren oder Änderungen an die APs verteilen lassen!?

Der Controller läuft auf einem Ubuntu-18.04er--Linux. Es handelt sich um eine VM, die auf einem Proxmox-Host läuft. Ich habe der VM 12GB RAM und 6 CPU-Cores verpasst. Das sollte mehr als genug sein!? Load Average der letzten 15 Minuten zeigt 0.09, was darauf hindeutet, dass sich die VM größtenteils langweilt.

Was die Verkabelung angeht: Der Proxmox-Host ist über ein 2x 10GBit LAG mit einem Unifi-16XG verbunden -- von da aus geht's per LAG weiter zu den nächsten Switches (Cisco PoE). Dort hängen dann die Accesspoints an 1GBit-PoE-Ports. (Wir haben fast nirgendwo eigene Injektoren verwendet.)
Kann es sein, dass ein einziges defektes Kabel solche Efffekte im gesamten VLAN auslöst? Also auch über diverse Switch-Grenzen hinaus? Es sieht jedenfalls stark danach aus, als ob alle Accesspoints dieses Verhalten zeigen. Gerade habe ich nochmal auf dem Controller nachgesehen: Da ist ~ alle 5-Minuten irgendein Accesspoint mit der Meldung "getrennt" fällig - extrem nervig.

Den Artikel für größere Umgebungen kannte ich bisher nicht ... lese ich gerade! Können wir die Datei

/var/lib/unifi/system.properties

hier mal miteinander vergleichen? Vielleicht sind ja noch ein paar andere Einstellungen nicht so optimal wie sie sein könnten!? Erste Erkenntnis übrigens: Es reicht nicht aus, wenn man der VM einfach nur mehr Speicher gibt ... man muss auch Java erlauben, sich mehr davon zu nehmen...

Es sind viele Accessponts -- die können nicht alle fehlerhafte Kabel haben? Es ist kein System erkennbar, aber die APs sind alle irgendwann mal "dran". Im syslog scheint es so zu sein, dass der AP immer dann "getrennt" meldet, wenn im Log diese Meldung erscheint:

Sat Oct  8 19:46:36 2022 daemon.notice /usr/bin/mcad[3596]: Found Backup1 on[1] ...
Sat Oct  8 19:46:36 2022 daemon.notice /usr/bin/mcad[3596]: Found  Active on[2] ...
Sat Oct  8 19:46:36 2022 daemon.notice /usr/bin/mcad[3596]: Storing Active[1] ... [%100]
Sat Oct  8 19:46:37 2022 daemon.notice /usr/bin/mcad[3596]: Active->Backup[2] ... [%100]

Das passt von der Uhrzeigt genau überein ... die Frage ist nur: Warum?

Hallo.

Leider habe ich hier ein sehr nerviges Problem mit unseren Unifi-Accesspoints: Im Controller wird alle paar Minuten für ständig wechselnde Accesspoints gemeldet, dass sie getrennt wurden ... ein paar Sekunden später sind sie wieder da. Ich habe die Accesspoints bereits mit Smokeping "überwachen" lassen: Sie sind dauerhaft pingbar. Daher kann ich eigentlich ausschließen, dass die Verbindundung vom Accesspoint zum Controller zwischendurch weg ist.

Was seltsam ist: Wenn man sich per ssh anmeldet und nachsieht, was bei "tail -f /var/log/messages" los ist, steht da öfter dies:

Sat Oct  8 19:29:34 2022 daemon.err mcad: mcad[3597]: ace_reporter_trsp_curl.check_multi_info(): inform failed with curl code 52
Sat Oct  8 19:29:34 2022 daemon.err mcad: mcad[3597]: ace_reporter.reporter_fail(): Unknown[12] (http://192.168.1.100:8080/inform)
Sat Oct  8 19:29:34 2022 daemon.err mcad: mcad[3597]: ace_reporter.reporter_fail(): inform failed #1 (last inform: 90 seconds ago), rc=12

Die IP des Controllers ist aber erreichbar und ein CURL direkt auf der Konsole abgesetzt kommt auch an! Daher frage ich mich, was da los ist bzw warum das inform scheitert? Es ist die aktuelle Version des Controllers (7.2.94) und die ganz aktuelle Version der AP-Firmware installiert: 6.2.39.14077

Man findet zu diesem Problem diverse Treffer im Netz -- aber nirgendwo steht eine zufriedenstellende Lösung.

Vielleicht hat hier jemand eine gute Idee

Hallo.

Wir haben einen Ticket-Drucker, der per Knopfdruck ein Voucher drucken kann. Das ganze lief bisher tadellos auf einem RasPi-Zero. Seit ein paar Tagen kommt leider kein Ticket mehr an. Nun bin ich auf Fehlersuche gegangen. Da der Ticket-Drucker richtig initialisiert wurde und auch Kontakt zum Controller hat, fürchte ich nun, dass sich der Fehler mit dem Upgrade des Controllers von Version 6.0.55 auf 7.1.61 eingeschlichen haben könnte?!? Kann es sein, dass ich mit dem Major-Upgrade etwas an der API geändert hat?
Leider kann ich es im Moment nicht genauer eingrenzen aber vielleicht hat ja jemand eine gute Idee...

Hm -- ich finde die Stelle im Controller gar nicht, wo man da was umstellen kann!?

Verstehe ich nicht ... die 10GBit wurden doch automatisch richtig ausgehandelt. Zudem sind es LAGs, bei denen dieses Problem auftritt ...

Die Verbindung vom Unifi-Switch zum Server ist keine 3 Meter lang ... Es sind die typischen LC multi-mode Kabel in aquamarin ... 10 GBit sollten da also locker durchgehen.

Ein Test mit iperf3 bestätigt das übrigens auch...

Ja, IPs passen ... sie kommen wie gesagt von der OPNSense und liegen im Bereich

172.16.0.1 bis 172.16.7.254 (Netzmaske 255.255.0.0) -- also ein rel. großer Bereich.

Alle anderen Domains können ja auch aufgerufen werden ... nur eben nicht service.meine-domain.de. Ich möchte auch gar nicht ausschließen, dass das Problem evlt auf dem Webserver zu suchen ist ... aber seltsam ist es doch schon, dass es bei deaktiviertem Gastportal sofort funktioniert?!? Da liegt es rel. nahe, zunächst dort zu suchen!??

Es ist ein eigenes Portal -- aber auch daran liegt es nicht, da wir natürlich auch schon das unifi-eigene Default-Portal ausprobiert hatten: Gleiches Problem. Das Portal selbst ändert ja auch nichts an irgendwelchen DNS-Einstellungen, sondern lässt nur durch, wenn man sich richtig anmeldet hat bzw über einen gültigen Code (Voucher) verfügt...