Live data from Hacker News

Reverse-engineering the UniFi inform protocol

tamarack.cloud

11–20 of 81 posts

Re: Reverse-engineering the UniFi inform protocol

#11
It seems like a pretty tall order, but I really want an open source access point controller daemon that knows how to provision and manage a wide variety of APs from different manufacturers.

So you'd have one services that can provision Ubiquity, MikroTik, TPLink and other APs and manage the clients.

Re: Reverse-engineering the UniFi inform protocol

#12
Nice trick. Just a heads up that I had to whitelist your domain as NextDNS blocked it for being newly registered.

Given this thread will probably attract other Unifi users... has anyone had success migrating from MongoDB to something like FerretDB?

I played around with getting this to work a few weeks ago and found that day-to-day it works without issue, but restoring a backup will error since it relies on some unsupported Mongo semantics (renaming collections iirc).

Re: Reverse-engineering the UniFi inform protocol

#14

Nice trick. Just a heads up that I had to whitelist your domain as NextDNS blocked it for being newly registered. Given this thread will probably attract other Unifi users... has anyone had success migrating from MongoDB to something like FerretDB? I played around with getting this to work a few weeks ago and found that day-to-day it works without issue, but restoring a backup will error since it relies on some unsup…

What does an admin do about NextDNS blocks?

Re: Reverse-engineering the UniFi inform protocol

#15

Is it just me that pretty much cannot read most of the text in the "Reading the MAC" code block? I don't know if it's because I use dark mode, but some of the text is #24292E on top of #141A16, which for me at least is practically invisible

Sorry about that, I typically use light mode, fixed and deployed!

Re: Reverse-engineering the UniFi inform protocol

#16

Do I miss something? How do you adopt the device in the first place? If you have to SSH into the device and set the inform URL manually could't you just route the request based on the request hostname?

Yep, once you set-inform the host header handles the routing. This in particular is most useful for things like DHCP Option 43, where devices only get an IP.

Re: Reverse-engineering the UniFi inform protocol

#17

Is it just me that pretty much cannot read most of the text in the "Reading the MAC" code block? I don't know if it's because I use dark mode, but some of the text is #24292E on top of #141A16, which for me at least is practically invisible

Sorry about that, I typically use light mode, fixed and deployed!

A million times better, thanks =)

Re: Reverse-engineering the UniFi inform protocol

#19

Do I miss something? How do you adopt the device in the first place? If you have to SSH into the device and set the inform URL manually could't you just route the request based on the request hostname?

Yep, once you set-inform the host header handles the routing. This in particular is most useful for things like DHCP Option 43, where devices only get an IP.

But if you only got that IP and a MAC-Address - how do you know which tenant is supposed to adopt the device?

Re: Reverse-engineering the UniFi inform protocol

#20

It seems like a pretty tall order, but I really want an open source access point controller daemon that knows how to provision and manage a wide variety of APs from different manufacturers. So you'd have one services that can provision Ubiquity, MikroTik, TPLink and other APs and manage the clients.

Now that would be interesting! Multi-vendor support is on the radar, but haven't started looking into it much yet.
Post reply on HN