The Curious Case of the Unadoptable WAPs

by

I come across many intriguing problems throughout my work. I want to share these stories, how I work through these problems and of course, the answers I find along the way so others can benefit from it, should they encounter the same issue.

Image generated by ChatGPT

The Setup

This problem started when I wanted to adopt a new wireless access point (WAP) to our UniFi controller that is hosted in the cloud. For those unfamiliar, you can have multiple locations, called Sites in UniFi lingo. Each site can have its own settings, SSID, etc. You can have a Ubiquiti device that hosts a controller at each location but with a cloud-based hosting solution, all you need is an internet connection for your WAPs to be connected and managed. Another added benefit is that you can adopt your WAPs from home, work, on location, wherever. The adoption process is fairly simple. You SSH into the WAP via the IP address, send a command, and your new WAP pops up on your controller, on all sites, so you get to choose where to adopt it to. Or that’s what’s supposed to happen…

When I was trying to adopt this WAP, I was at the office. We have the following simple setup:

  • Fortigate firewall
  • 2x Aruba 2530 switches
  • 2x Ubiquiti AC HD wireless access points

A remote location where this new WAP would be adopted has a similar configuration. The ISP is Starlink rather than COX and the Fortigate firewall version is slightly different. So, I plug in the WAP that I want to adopt, and the light starts blinking white on it. I do an IP address scan to find the address, open up PuTTY to SSH in and log in. The simple help command shows us the basic functions that the WAP can perform:

help shows useful commands for the WAP

The command that sets a WAP up for adoption to a controller is as follows:

set-inform http://ipaddressofcontroller:8080/inform

And then it should pop up in your controller, whether it’s local or in the cloud with an orange symbol:

2 WAPs Offline

The Problem

Not only did the WAP not show up for adoption in the cloud controller, the two office WAPs were disconnected from the cloud controller (they should have green dots on the left, instead their dots are gray). Even more puzzling, the WAPs were still providing wireless access, which was nice! So, to get them back online, I started picking off the low-hanging fruit. Ran the reboot command to restart them. I had help in accessing the cloud controller and restarting the entire machine that runs that (thanks Justin!). Still the same result. Resetting and re-adopting to the controller – a troubleshooting step I have used before – was out of the question because of my current issue: adoption was not working. Even more puzzling (or maybe as the first clue to the solution), the remote site was not having this issue:

Different location, the WAPs are all connected and communicating with the cloud controller

All green on statuses at the remote location. That’s good. So it must be something at the office. Next, I connected to one of our local WAPs to see if it had any clues for me:

That’s not the status I was hoping to find.

Okay, so we have a status that’s not normal: Unknown [12]. By the way, default credentials to the WAP is username ubnt and password ubnt but as soon as it’s adopted, like the one in the picture, the SSH credentials will be provided by the controller and they are site specific. I learned this the hard way, trying one site’s credentials to the other. It did not work out.

Unfortunately Unknown [12] status seemed to have a lot of different causes for forum users. When I looked at my own setup, they all seemed to be correct on my WAP. Date was correct. NTP was able to synchronize. There were no changes made to our switches recently.

Author's Note: while writing this up and providing sources, I searched for "unifi status unknown 12," like I did while trying to solve this issue. The second result, had I checked it at the time I was working through this problem, would have provided the solution.

Some additional sleuthing led me to the helpful command of cat /var/log/messages which gives additional details with what’s going on with the WAP. Here is an excerpt:

Tue May  6 13:01:51 2025 daemon.err mcad: mcad[1356]: ace_reporter.reporter_fail(): Unknown[12] (http://xxx.xxx.xxx.xxx:8080/inform)
Tue May  6 13:01:51 2025 daemon.err mcad: mcad[1356]: ace_reporter.reporter_fail(): initial contact failed #69, url=http://xxx.xxx.xxx.xxx:8080/inform, rc=12
Tue May  6 13:01:51 2025 daemon.info mcad: mcad[1356]: ace_reporter.reporter_next_inform_method(): next inform family: 2
Tue May  6 13:01:52 2025 daemon.warn mcad: mcad[1356]: url_resolv.evdns_resolv4_cb(): dns host unifi resolv failed, result=3/name does not exist, type=0, count=0, ttl=362

I didn’t get much from this except that it does seem like the WAP can’t talk to the controller. DNS has not changed recently so I moved past that too. The ping command on the WAP was working when pinging the controller’s IP address. So is it working or not?

I kept looking online and made a break with this post. I was looking at his troubleshooting steps and there was one I had not tried yet:

curl -vv http://ipaddressofcontroller:8080/inform

curl to establish a connection, -vv for very verbose modifier, meaning we want all of the response back from the address and finally the address of our cloud controller. I found something that was different with the response I got from the thread above:

CORP-1STFLOORKITCHEN-BZ.6.6.77# curl -vv http://ipaddressofcontroller:8080/inform
> GET /inform HTTP/1.1
> Host: ipaddressofcontroller:8080
> User-Agent: curl/8.4.0
> Accept: */*
>
< HTTP/1.1 403 Forbidden
< X-Frame-Options: SAMEORIGIN
< X-XSS-Protection: 1; mode=block
< X-Content-Type-Options: nosniff
< Content-Security-Policy: frame-ancestors 'self'
< Content-Type: text/html; charset="utf-8"
< Content-Length: 35521
< Connection: Close

Okay. Getting somewhere! The inform address is getting blocked! My bet at this point is that it is firewall related. Just as a hunch, I tried the inform address in the web browser to see what I got:

The firewall was blocking the inform URL!

While I can click past this, obviously the WAP cannot, so the connection is blocked and it cannot do a handshake with the controller.

The Solution

Once I knew the culprit, it was an easy solution. I tried modifying our firewall rule under Policy & Objects section of the firewall but after applying the bypass rule for this IP address, it did not work.

Next I headed over to Security Profiles -> Web Filter and used a URL bypass on the web filter policy:

This SHOULD make it so the inform URL does not go through the firewall web policy filtering.

I checked back on the cloud controller after saving the change:

This was very satisfying to see as it INSTANTLY lit up as green after I saved the URL bypass on our Fortigate firewall.

Lessons Learned

I was pretty happy with how this got resolved over a day or two of work and that there wasn’t really any user impact since the WAPs were still working while not being able to communicate with the cloud controller. I would go about things similarly, even knowing the answer at the end. Restarting devices / services is often enough to restore connectivity. I couldn’t find the firmware update date on our firewall, but I suspect something got updated in the past few weeks to trigger this. Logs on UniFi showed disconnection from cloud controller in the middle of April.

Also, please check the second search result on Google and save yourself a few hours next time 🙂

Thanks for following along,

Kristof

Leave a Comment