Reverse-engineering the UniFi inform protocol

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).

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.

"The whole proxy is maybe 200 lines of Go with an in-memory MAC-to-tenant lookup table." Is it possible to have the source code or is it private ?

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?

This is very cool.

I wonder if there's a way to control routing client side and remove the list of mac addresses. Eg manage DNS for customers (upsell ad blocking!) and CNAME the unifi entry to a customer specific vhost.

I don't quite get the reason for sniffing the packets. Wouldn't it be simpler to just run multiple VMs on one host to be multi tenant?

Nice hack! Would hosting controllers on individual IPv6 addresses on the same VM solve this too?

> ("TNBU" is "UNBT" backwards, presumably UniFi Broadcast Technology.)

This seems like an odd misunderstanding, especially because the correct inversion “UBNT” is the default login name for most UniFi web UIs.

You might have a bit of dyslexia, OP!

Bit of a thread-jack, but has anyone reverse-engineered the UniFi camera adoption protocol? I was surprised to discover that, unlike the APs, the cameras can't be adopted through the Unifi Software Controller that you can just throw into a Docker container. You're supposed to do that through their NVR appliance (Unifi Protect). I was hoping to just use them with my open-source NVR. They seem to be about the only option for a reasonably priced, larger image sensor camera that is not made by a company participating in the Uyghur genocide (Hikvision, Dahua, Univision, Huawei).

I found https://community.home-assistant.io/t/unifi-cameras-without-... in which someone sshed in, edited some config files by hand, and got streaming to work for the current boot. One could probably take that a bit further and, you know, save the config to flash. But it'd be nice to just do it the way their controller does and know it's going to work for future firmware updates and such.

They also stream by connecting to your NVR with modified version of flv, rather than you connecting to them with RTSP, which is annoying but can be worked around.

  | Hex Code | Field | Data |
  |----------|-------|------|
  | `0x01` | MAC Address | 6-byte hardware address |
  | `0x02` | MAC + IP | Combined MAC and IPv4 address |
  | `0x03` | Firmware Version | String |
  | `0x0B` | Hostname | String |
  | `0x0C` | Platform (Short Model) | String |
  | `0x0A` | Uptime | 64-bit integer |
  | `0x13` | Serial | String |
  | `0x14` | Model (Full) | String |
  | `0x17` | Is Default | Boolean (adopted vs unmanaged) |

    GET /camera/1.0/ws HTTP/1.1
    Pragma: no-cache
    Cache-Control: no-cache
    Host: ...
    Origin: http://ws_camera_proto_secure_transfer
    Upgrade: websocket
    Connection: close, Upgrade
    Sec-WebSocket-Key: ...
    Sec-WebSocket-Protocol: secure_transfer
    Sec-WebSocket-Version: 13
    Camera-MAC: ...
    Camera-IP: ...
    Camera-Model: 0xa601
    Camera-Firmware: 5.0.83
    Device-ID: ...
    Adopted: false
    x-guid: be9d8e45-62a8-ae84-8b23-71723c7decaf

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

Controller uses way to much RAM compared to OpenWISP and good luck if a device is EOL. Lots of $10 USG-3P's out there.

[dead]

I'm glad the payload was usable and the author has fixed their problem, it's an interesting challenge.

However, there are other approaches. A public IP per client isn't going to be nearly as expensive as a VM per client, and lets you route your clients by target. Or you could route by source IP: either by having the client register their IPs, or with some combination with seeing where folk log in from.

Neither is necessary, though, given inspection does appear to work.