My house has four Ubiquti Unifi AP-AC-LR access points. Out of whatever reason, the construction of the house seems to attenuate WIFI signals significantly from one floor to the other, so i have an LR AP in the cellar, first floor, second floor and in the roof. A while ago i moved my Unifi controller into a docker container and I changed the IP address with it. Of course, i reconfigured everything, so all the devices used the new Unifi controller.

Fast forward a few weeks. Out of whatever reason all those access points switched themself back to the old IP addresses in regard of the inform server. All of them appeared as offline on the device page of the Unifi UI.

In this blog entry aaa.bbb.ccc.ddd is the old Unifi Controller, whereas aaa.bbb.ccc.eee is the new one. The access point is aaa.bbb.ccc.fff

I tried to fix this by logging into the AP and execute an

APErdgeschoss-BZ.6.5.62# set-inform http://aaa.bbb.ccc.ddd:8080/inform 

But to no avail, the persistent configuration stayed incorrect. The access points are switching “up to date” for a while and i was able to manage it for a while, but after some time (or rebooting) they switched back to “offline”.

So i checked for the configuration.

APErdgeschoss-BZ.6.5.62# info

Model:       UAP-AC-LR
Version:     6.5.62.14788
MAC Address: aa:bb:cc:dd:ee:ff
IP Address:  aaa.bbb.ccc.fff
Hostname:    APErdgeschoss
Uptime:      5346 seconds
NTP:         Synchronized

Status:      Unreachable (http://aaa.bbb.ccc.ddd:8080/inform)

There was the IP address of the old Unifi controller again and this has been decommissioned for a while (It’s a first gen cloud key laying around in my drawer now). So, it was of course unreachable.

When you log into the access point via ssh, you will find a directory /cfg with a file called mgmt

APErdgeschoss-BZ.6.5.62# cat mgmt 
mgmt.is_default=false
mgmt.led_enabled=true
mgmt.cfgversion=000000000000000000
mgmt.authkey=0000000000000000000000000000000000
mgmt.selfrun_guest_mode=pass
mgmt.capability=notif,notif-assoc-stat
mgmt.use_aes_gcm=true
mgmt.report_crash=true
mgmt.is_setup_completed=false
mgmt.servers.1.url=http://aaa.bbb.ccc.ddd:8080/inform
stun_url=stun://aaa.bbb.ccc.eee/
mgmt_url=https://aaa.bbb.ccc.eee:8443/manage/site/default

Of course, I tried to change it by editing the file and rebooting everything. But that didn’t work either. As far as i understand the mgnt file is generated at boot from flash.

So, you must actually write the data into this flash before rebooting. I used the following commands after editing the file:

APErdgeschoss-BZ.6.5.62# syswrapper.sh save-config
APErdgeschoss-BZ.6.5.62# syswrapper.sh apply-config
APErdgeschoss-BZ.6.5.62# reboot

The apply-config should suffice. But I’m not perfectly sure of it. And i corrected all four AP before having the idea to try only apply-config

Nevertheless … after login into the access point via ssh the configuration was correct and the access point appeared with “up to date” in the list of devices

APErdgeschoss-BZ.6.5.62# info

Model:       UAP-AC-LR
Version:     6.5.62.14788
MAC Address: aa:bb:cc:dd:ee:ff
IP Address:  aaa.bbb.ccc.fff
Hostname:    APErdgeschoss
Uptime:      83 seconds
NTP:         Not synchronized

Status:      Connected (http://aaa.bbb.ccc.ddd:8080/inform)

I just wasn’t able to recover one of the access points this way. Out of whatever reason the ssh password didn’t worked. I assume, an older ssh password was still configured on the device. A password i didn’t have. So, i had to reset it. Of course, this was the one most difficult to reach. At the end i was able to reach it, but with a clear OSHA respectively UVV violation to reach this access point.

Written by

Joerg Moellenkamp

Grey-haired, sometimes grey-bearded Windows dismissing Unix guy.