Adoption Failed nach Migration

Es gibt 6 Antworten in diesem Thema, welches 1.779 mal aufgerufen wurde. Der letzte Beitrag () ist von ꧁𓊈𒆜 ƁєηLυє 𒆜𓊉꧂.

    Hallo,


    ich habe in der letzten Woche unseren Unifi Controller von einem virtuellen System in einer Cloud auf eine anderes System in einer neuen Cloud umgezogen.

    Vorgehen war:


    Sicherung machen

    Sicherung einspielen

    DNS-Record umziehen


    Alle Geräte haben sich wie erwartet an dem neuen Controller angemeldet. Nun wollte ich die ersten Geräte neu verbinden.

    Hierzu gehe ich per SSH auf das jeweilige System und setze den set-inform Befehl ab.


    Das Gerät taucht dann am Controller auf. Wenn ich nun den Prozess am Controller starte und den Befehl auf dem Gerät erneut absende (Was in der Vergangenheit den Prozess deutlich beschleunigt hat) wechselt das Gerät auf "ADAOTION FAILED".


    Dis tritt sowohl bei einem neuen Switch, als auch bei einem neuen AP auf. Firmware wurde bei dem AP manuell aktualisiert um Probleme hier auszuschließen.


    Ich habe zum Test nun schon alle Ports auf der Firewall erlaubt, Ergebnis bleibt aber unverändert

    Im Log auf dem Contriller sehe ich dies:




    [2022-11-28T12:05:33,220] <inform-3> WARN inform - dev[d0:21:f9:e4:eb:60] used default key in ADOPT_FAILED state, reject it!



    Habe ich was bei der Migration vergessen?

    Mach mal folgendes:


    • Im Controller -> Forget AP
    • Via SSH auf deinen AP folgenden Befehl ausfürhren: set-inform http://<deine controller ip>:8080/inform


    LG

    Ben

    ⢀⣴⠾⠻⢶⣦⠀ Debian - The universal operating system user
    ⣾⠁⢠⠒⠀⣿⡁ https://www.debian.org
    ⢿⡄⠘⠷⠚⠋⠀
    ⠈⠳⣄⠀

    :right_arrow: Dumme Gedanken hat jeder, nur der Weise verschweigt sie. (Wilhelm Busch) :left_arrow:

    Ergänzung:


    Ein Gerät ließ sich nun verbinden, der AccessPoint schlägt weiter fehl.


    Was mir auffählt, wenn ich auf ADVANCED ADOPT gehe, steht dort die interne IP-Adresse des Cloud-PCs NICHT die externe.

    Kann das damit zusammenhängen?


    [2022-11-28T12:45:03,809] <ubnt/tcp1> WARN dev - [sshCommand exec] Execute SSH without host key verification!

    [2022-11-28T12:45:06,811] <ubnt/tcp1> ERROR dev - SSH adopt failed adopt_state[2],prev_state[0],firmware[6.2.44.14098],model[U7PG2],uses_default_credentials[true]

    [2022-11-28T12:45:15,037] <inform-3> WARN inform - dev[70:a7:41:83:f1:1c] used default key in ADOPT_FAILED state, reject it!

    Kommt drauf an. Ich hatte mein Controller mal draussen im Internet. Dann musste ich logischerweise die extene IP verwenden. Befindet sich dein Controller im Heimnetz, ist es ratsam die interne IP zu verwenden!

    ⢀⣴⠾⠻⢶⣦⠀ Debian - The universal operating system user
    ⣾⠁⢠⠒⠀⣿⡁ https://www.debian.org
    ⢿⡄⠘⠷⠚⠋⠀
    ⠈⠳⣄⠀

    :right_arrow: Dumme Gedanken hat jeder, nur der Weise verschweigt sie. (Wilhelm Busch) :left_arrow:

    Weitere Ergänzung.


    Es klappt wenn:


    Ich den Adopt Prozess starte

    Adopt Annehme

    Den Contorller beende und wieder starte

    Adopt erneut ausführe.


    Das kann ja nicht richtig sein


    Natürlich gebe ich für den Adopt die externe IP bzw. einen DNS-Record an.

    Keine Ahnung, mir ist jedoch beim Umzug aufgefallen, als ich meine UDM SE resetten musste, wollten sich die AP's mit meinen alten Controller UCK2+ verbinden und waren es auch. Liegt warscheinlich am cache vom AP. Ich bin folgendermassen vorgegangen: Auf der UCK2+ Forget AP's, UCK2+ vom Netz genommen und die AP's an meine UDM SE eingebunden, später UCK2+ im Netz starten lassen. Bisher keine Probleme mehr...

    ⢀⣴⠾⠻⢶⣦⠀ Debian - The universal operating system user
    ⣾⠁⢠⠒⠀⣿⡁ https://www.debian.org
    ⢿⡄⠘⠷⠚⠋⠀
    ⠈⠳⣄⠀

    :right_arrow: Dumme Gedanken hat jeder, nur der Weise verschweigt sie. (Wilhelm Busch) :left_arrow: