Unifi: Manual switch adoption
I suspect, like much of the internet, I’m growing less and less enamoured with my Unifi network setup. The latest crouton on the shit sandwich is what’s arguably a SLAPP lawsuit against a journalist - I’m no huge fan of Krebs (at least this one, the other one’s great!) but this just strikes me as really tone-deaf… no one gave a shit about the last time they got hacked, but this has brought it all flashing back and is not a great look.
Anyway, so I’ve been dicking around with the idea of replacing it, and I keep looking at Mikrotik’s stuff. A PoE switch with SFP+ is still going to burn a hole in my wallet, and I haven’t quite sorted out what I would do for a router yet (they make what appear to be quite nice routers, but I’ve no experience with them and to be truthful I’d be perfectly happy with some sort of embedded device running Alpine Linux if it can do wire-speed NAT). I’ve got a lead on where I can get some modern Ruckus APs in Australia for a reasonable price, so all that remains is tearing the bandaid off… not happening this month because we’re putting a tow-hitch on the Commodore, but I’m thinking it will happen fairly soon.
In the mean time, I started cleaning up our network a bit, shifting RJ-45 terminated solid-core CAT5e over to the punchdown block I bought, installed, and never wired. In the process of doing so I started to think about what to do for a top-of-rack switch for my server cabinet, and remembered that I have an extra 8-port Unifi switch laying around.
The problem? I un-adopted it because I got sick of seeing “your system needs attention!” in big red writing on the top, because it wasn’t plugged in as I wasn’t using it. This should be fairly easy to figure out, I’ll just factory reset it and I should be able to easily adopt it.
No such luck. After following a guide on resetting it, I was left with a solid white LED after some time, ready to adopt, but it still didn’t come up on the controller. Indeed, it wasn’t even collecting a DHCP address (it showed up as a “client” rather than in the device list, listed only by it’s MAC address), and I’m not sure why that is (apparently there is/was an issue with very-large subnets, Unifi’s switches will reject the lease). I thought maybe it was my Kubernetes setup, but all the ports that they recommend are indeed configured, though I don’t think I can do “Layer 2 discovery” on it. I updated my controller to the latest version, thinking that maybe that would be why (it certainly shouldn’t be).
After some time, I unplugged the device from the network, power cycled it, and connected my laptop to it. I manually configured an IP in the default block they choose: ip addr add 192.168.1.1/24 dev enp2s0
- sure enough, I can ping 192.168.1.20
which is the default IP the switch will select.
So I ssh to it, which I can’t do because my “modern” SSH doesn’t like the hostkey algorithms the switch chooses, presumably as the switch’s firmware is rather old at this point. But I’m eventually able to connect with:
# FWIW, the default password is: ubnt
ssh -oHostKeyAlgorithms=+ssh-dss ubnt@192.168.1.20
I check things out, plug it back into the LAN and I get disconnected. It seems like perhaps it’s picking up an IP after all, since it’s stopped responding on the default one, but it’s not showing anything in the Unifi controller (it showed up as a client instead of a device, but did not show an IP). It’s at this point I notice that it’s picked up an IPv6 address that’s in my delegated /48, which pretty much confirms that conclusion: it’s grabbing an IP, but Unifi’s controller refuses to show it to me.
So I ssh back into it using the IPv6 address, and grab the IP. But then I think, I can probably just set-inform
at this point and trigger the adoption process anyway. So I just:
set-inform http://xx.xx.xx.xx:8080/inform
# where xx.xx.xx.xx is the IP of my Unifi controller, exposed from K8s
Finally, it popped up in the devices list and I was able to adopt, and update it!