Accesspoints melden ständig "getrennt" und wieder "verbunden"

Es gibt 10 Antworten in diesem Thema, welches 2.326 mal aufgerufen wurde. Der letzte Beitrag () ist von santinella9763.

    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:

    Code
    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:question_mark:

    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:


    Code
    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?

    Moin,


    eine der Fehlermeldungen:

    Zitat von white_rabbit

    inform failed with curl code 52

    Eine Fehler Meldung der CURL Lib

    CURLE_GOT_NOTHING (52)

    Nothing was returned from the server, and under the circumstances, getting nothing is considered an error.


    Für die Anfrage ist also NICHTS vom Controller zurückgekommen. Das klingt danach als wenn dieser

    also grade keine Lust hat antworten. Wenn es bei „allen“ AP passiert und nach ein paar Sekunden gehts wieder

    ist das ein Zeichen das der Controller mit was anderen beschäftigt ist oder grade nicht kann und den Request verwirft.

    Nach ein paar Sekunden ist dann wider gut.


    Worauf läuft den der Controller ? evt. hat er zuwenig Speicher oder andere Programme haben

    Priorität ? Der ganze Controller ist eine eine JavaApp. Zu wenig

    Speicher kann da tödlich sein. Kennst du DIESEN Artikel ? Da gibt es Anleitungen

    um unterandrem um mehr Speicher zuzuweisen.


    Ne andere Geschichte währe grundlegende Netzwerk Connectivity Probleme mit

    dem Controller. Ist der sauber angebunden (hast mit smoke Ping auch ihn Überwacht)

    Nicht das genau das Kabel Doof ist. Oder das auf dem Weg oder dem host selber

    irgend ein RateLimit läuft

    Ein falscher "inform Host" Eintrag im Controller kann auch seltsame Sachen hervorrufen, prüfen ob er auf Default oder custom steht, bei letzteren die IP checken ob sie mit dem Controller übereinstimmt.

    Hallo.

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

    Code
    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...

    Das Problem gab es schon mal bei einer älteren Controller Version. Immer beim backup haben sich die Dinger verabschiedet. Welche Version hat dein Controller und die APs?

    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.)

    Zitat von white_rabbit

    es muss also noch etwas anderes sein.

    Na ja, wenn die AP CURLE_GOT_NOTHING (52) melden dann solltest du rausfinden warum es periodisch vorkommt

    das der Controller „NICHT“ zurückgibt. Ne Verbindung scheint ja aufgebaut zu werden

    sonst würde es was wie „no Connection, CURLE_COULDNT_CONNECT, timeout“ geben.

    Wenn Der Dienst dahinter aber „nichts“ antwortet scheint es dem Dienst ja nicht soo gut zu gehen.

    Jedenfalls bis zu nächsten Anfrage wo wieder offensichtlich eine Antwort kommt.


    Irgendwelche Rate Limit Geschichten aktiviert in Proxmox ?

    Btw. Container oder VM ? ( kann mich entsinnen das Java und Container Problematisch war, aber was allgemeines nicht auf unifi bezigen) Eine Kompatible Java Version ?


    bzw: Jkasten meint das der Controller sich gerne aufhängt / aufgehangen hat wenn ein backup durchgeführt wird

    (im Controller selber)

    Einmal editiert, zuletzt von gierig ()

    Hallo,

    kommt mir irgendwie bekannt vor.

    Hatte dieses Problem im Zusammenhang meiner AP-PROs mit meinem Crontroller (7.2.92) (auf einem Raspberry laufend). Mein Thread in diesem Forum (Probleme mit AP Firmware 6.2.35). Nach dem Downgrade funktionierte wieder alles. Hab mich, wie im Thead angekündigt, aber noch nicht getraut, auf die neue 39er zu upgraden, da ich bereits auch hier von Problemen gelesen hatte.