You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Sadly, unifi does not actually document the adoption protocol. For those who come after me here is what I found. If some or all of my observations can be reproduced, a few hints in the Readme.md might help others.
importing a backup-configuration without unifi-cloud account (skipping in advanced) will result in a broken installation. The password of the backed up state cannot be used (at least for me)
when re-adopting all unifi devices (or switching them from another site) normal adoption hints do not suffice: setting the inform url will not suffice and will end in a rejected state on those devices (can be seen by ssh-ing, into the device an using the info command. Devices will not show up in the UI. (This can be found in unifis forum wel searching for rejected devices, too)
2.1 to remidy device rejection on adoption unifi states one has to factory reset the devices. Note, that factory reset via ssh does not suffice here, physical access to all devices is needed.
2.2 if the device is a USG (aka rotuer) and the desired subnet is not 192.168.1.0/24 after factory reset the devices ip-address needs to be changed through ssh (an option to do so in it's web-UI exists, but is ignored during adoption, resulting in adoption failure stateing the the router power cable might be broken, when in fact it just reverted to it's default address 192.168.1.1 and cannot be reached from the container. Note that unifis documentation states that in addition to that a working DHCP server in the target network is needed, this could not be replicated, the device did not pull an address or network configuration from the server. This makes sense as in default configuration the USG act as DHCP server.
2.3 It might nor might not be possible to change the system.properties to include the correct (hosts) ip. I did so, but cannot be sure if this does more than change the string displayed in the web-UI.
Reason for change
Had a bit of an afternoon getting everything back up. it quite possible is just my fault, but if others report similar issues, we could add some additional instructions here. I have little hope to contribute/enhance unifis own documentation.
Since there is some precedent for information like this in the repos Readme.md I propose it here. If this is understandably not suitable (this is the documentation of the container not the product after all), this issue may at least be found by others troubleshooting their setup.
Proposed code change
if the imported backup configuration is not connected to a unifi-cloud account the import process might fail
when trying to adopt devices from different sites (or after configuration import failure) factory reset using the hardware buttons is neccesarry.
when adopting USG (aka router) devices into networks other than 192.168.1.0/24 its ip-address must be changed via ssh (not webUI)
The text was updated successfully, but these errors were encountered:
This issue has been automatically marked as stale because it has not had recent activity. This might be due to missing feedback from OP. It will be closed if no further activity occurs. Thank you for your contributions.
Is this a new feature request?
Wanted change
Sadly, unifi does not actually document the adoption protocol. For those who come after me here is what I found. If some or all of my observations can be reproduced, a few hints in the Readme.md might help others.
importing a backup-configuration without unifi-cloud account (skipping in advanced) will result in a broken installation. The password of the backed up state cannot be used (at least for me)
when re-adopting all unifi devices (or switching them from another site) normal adoption hints do not suffice: setting the inform url will not suffice and will end in a rejected state on those devices (can be seen by ssh-ing, into the device an using the
info
command. Devices will not show up in the UI. (This can be found in unifis forum wel searching for rejected devices, too)2.1 to remidy device rejection on adoption unifi states one has to factory reset the devices. Note, that factory reset via ssh does not suffice here, physical access to all devices is needed.
2.2 if the device is a USG (aka rotuer) and the desired subnet is not
192.168.1.0/24
after factory reset the devices ip-address needs to be changed through ssh (an option to do so in it's web-UI exists, but is ignored during adoption, resulting in adoption failure stateing the the router power cable might be broken, when in fact it just reverted to it's default address192.168.1.1
and cannot be reached from the container. Note that unifis documentation states that in addition to that a working DHCP server in the target network is needed, this could not be replicated, the device did not pull an address or network configuration from the server. This makes sense as in default configuration the USG act as DHCP server.2.3 It might nor might not be possible to change the system.properties to include the correct (hosts) ip. I did so, but cannot be sure if this does more than change the string displayed in the web-UI.
Reason for change
Had a bit of an afternoon getting everything back up. it quite possible is just my fault, but if others report similar issues, we could add some additional instructions here. I have little hope to contribute/enhance unifis own documentation.
Since there is some precedent for information like this in the repos
Readme.md
I propose it here. If this is understandably not suitable (this is the documentation of the container not the product after all), this issue may at least be found by others troubleshooting their setup.Proposed code change
192.168.1.0/24
its ip-address must be changed via ssh (not webUI)The text was updated successfully, but these errors were encountered: