A customer was consolidating two offices into one. Both were on the same UniFi controller. Each office had its own USG and its own range of IP addresses. I needed to move a switch to the new, consolidated site but wound up with a “Server Reject” adoption loop. Here are the steps that led to that issue and the solution.
The switch to be moved had a fixed IP. It was already offline by the time I started this process.
1. Open the switch in the dashboard. Under Config (gear icon) > Manage Device > Forget this device, do not click Forget but rather choose Move this device to… the new office.
2. Under Config > Network, update the Static IP to use an IP Address and Gateway in the IP range in the new office.
3. On site, connect the switch to the network in the new office. The switch started passing traffic on the new network. but in the dashboard, it still showed the old static IP and could not be managed. I connected a laptop directly to the switch, set the NIC on the laptop to a fixed IP in the old office’s range, and connected to the switch via SSH. When I ran info, it showed the correct set-inform status but I think it said “Unreachable”, which makes sense, since its IP was still on a different network.
4. I couldn’t find simple instructions to change the static IP of the switch, so I just did a restore-default to reset it to factory defaults. Note that this loses all custom configuration, ports names, etc. After this, the switch appeared in the dashboard with a dynamic IP in the new office’s IP range and immediately launched into an endless Adopting… loop. Adoption never completed.
5. Using the new dynamic IP, I was able to SSH into the switch with the default username and password (ubnt / ubnt). Now, info shows that the server is rejecting the adoption:
On the controller, I see hundreds of errors like this in C:\Users\<username>\Ubiquiti UniFi\logs\server.log:
[2020-07-09T18:45:21,552]ERROR inform - invalid fingerprint: expecting[e5:e6:2f:b5:9c:fe:a0:35:34:fd:84:bd:ba:a5:84:2e], payload={architecture=armv7l, board_rev=6, bootid=1, bootrom_version=usw-v1.1.4.115-g14af1ee6, cfgversion=?, default=true, dhcp_server_table=[{blocked=false, ip=x.x.x.x, last_seen=9516, mac=fc:ec:da:xx:xx:xx, port_idx=1, vlan=1}], discovery_response=false, dualboot=true, ever_crash=false, fingerprint=e6:87:89:c1:0f:8f:c6:54:b5:d1:a5:7b:6f:f1:f4:b3:74:c0:b1:4f, <snip>
Although not explained, the “invalid fingerprint” makes sense: before the factory reset, the device had a fingerprint corresponding to a configuration in the controller. That could have been adopted if the device’s IP address had allowed talking to the new network. However, issuing a factory reset generated a new fingerprint; the MAC for the device was known by the controller but the fingerprint was not, so it rejected the adoption.
The Solution
The solution was fairly simple: I needed to fully forget the device in the controller. The only trick was hitting the Forget button in the one-second gap between adoption attempts, when the status showed Disconnected. If you try to forget while the status is Adopting, it says that the device is busy.
Once the device had been removed from the controller, because its IP and set-inform were already correct, it immediately re-appeared in the controller as “Pending Adoption.” I just clicked the Adopt button in the controller and very soon saw the switch Connected in the new office. After that, I went back in and reset the switch’s name and Static IP.
Next Time
Next time, before disconnecting the switch at the old office, set it back to dynamic IP (“Using DHCP”), then choose Move this device to… the new office. In that state, the switch should be able to connect and re-adopt at the new location. Once adopted, set the Static IP for the new IP range as desired.
Thank you very much for this, I really appreciate you writing it up – I just lost 2 hours of my life trying to fix the endless “server reject” loop, and your solution worked like a charm.
It worked me too. I had similar problem. Something went wrong with my UAP-nano so i reset it brutally with pin. I thought it would work but it got in to this Adopt disconnect loop. I ssh into it with usr/pwd ubnt ubnt.
Checked all the advanced troubleshooting here https://help.ui.com/hc/en-us/articles/360012622613#troubleshooting-adoption-failed
Tryed everyting with dhcp /static/router/reset/slaping for hours.
From info cmd I got this Status: Server Reject (http://192.168.1.3:8080/inform) I finally tried to searched for “UAP nanHD info Status: Server Reject /inform” on DuckDuckGo
and found your solution that worked like a charm. I just clicked forget this device. Then it came back. After provisioning the AP i set it back to the static IP it had before. So now everything works great again. Thanks for your post you should have a buy me a beer button.
Great story, Patrik! Thanks for posting. Hopefully your references will get picked up by the Googlebot and make this article easier to find. I will definitely think about the beer button ;).
I had this same problem and when I tried to hit the button in between cycles it said that the Forget operation failed. I ended up having to SSH into the controller, shut down the unifi service, start the mongodb instance standalone, delete the device from the database:
use ace
db.device.remove({“mac”:”##.##.##.##.##.##”})”
– or –
db.device.remove({“name”:”my cranky UAP”})
then reboot the controller to get this working. Then I could adopt the device properly. That’s a few hours of my life I’m never getting back.
@CB, wow that’s brutal. I didn’t even know it was possible to manipulate the mongodb. What kind of server is your controller running on? This one was Windows, though I also have a Linux-based controller in the cloud.
THANK YOU! I was ready to get the mongo runtime and tear into the database! This worked like a charm. I figured out the timing was exactly 5 seconds after it quit trying to adopt! I hit FORGET at 3 seconds at boom.. dropped it instantly! thank you thank you thank you
This was awesome! Thanks so much! I had the same “server reject” problem! I had to do a “set-default” in the SSH terminal before the controller would let me “forget it”. I tried about 30 times to “forget” and it was always busy. Once I did the ‘set-default” the controller let go of it! Thanks!
Finally A solution thanks!
had this switch stacked on a broken pile :p
I tried to reset it the way you suggest.
but never had the chance too… the windows to press forget was too short
I rebooted it through ssh gave me some more time!