Reverse-engineering the UniFi inform protocol(tamarack.cloud) |
Reverse-engineering the UniFi inform protocol(tamarack.cloud) |
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).
We get this a lot at my job, where many customers' admins block s3 buckets by default. We give our customers a list of hostnames to allowlist and if they can't figure it out, that's on them.
So you'd have one services that can provision Ubiquity, MikroTik, TPLink and other APs and manage the clients.
Last time I've tried, it was not supported by any open source solution.
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!
> "TNBU" is "UNBT" backwards
TNBU is clearly NOT uNbt backwards.
Every network I've set up (which is not many) has a dns search suffix handed out by dhcp. So the wap will resolve, e.g. unifi.branch.megacorp.net with zero config needed.
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 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.
Setting where it sends the video stream.
Configuring video settings, zone detections, etc. I found a video going through them here: <https://youtu.be/URam5XSFzuM?si=8WK4Yghh9kidZe6c&t=279> Just about any other camera lets you change this stuff through the camera's built-in web interface and/or ONVIF. Ubiquitis apparently don't.
> Otherwise it's just a device on your network that you can configure Frigate etc. to connect to and pull streams.
No, it connects to you!
They claimed most of their customers aren't asking for it when I pushed them on the issue years ago.
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.
Having the client register their IPs isn’t tenable for most folks. What’s my IP at the shop? (No idea) Will it change? (Yes) now it’s broken.
Seeing where folks log in from isn’t nearly the same as where their UniFi networks are located. (Store vs home.) Broken.
So neither of the those are robust approaches whereas the author’s solution is bulletproof and simply works in all cases.
No offense, but why suggest “other approaches” that have such major holes? Why not just cheer on the solution that works all the time?
This protocol was amenable to inspection, the next might not be.
I use NextDNS, one of the features it provides is letting you register a source IP so requests from your network "just work". It might not be a mainstream consumer feature, but neither NextDNS nor managed Unifi controllers are mainstream consumer products.
a) optimize signal strength for coverage (stronger signals aren't always better in multi-AP deployment);
b) provide hints via 802.11k/v/r to help clients make, hopefully, better decisions;
c) forcefully drop and disassociate clients when signal is weak enough.
But if the client has bad WiFi implementation, there's nothing much you could do.
OpenWRT currently supports 802.11k/v/r, but optimizing coverage by adjusting signal strength and channels is left for experienced users to deal with manually. There is the are where some commercial offerings will do, but the result greatly varies. AFAIK there's no ideal system anyway coz physics is hard.
I think it should even be possible to get seamless roaming between Unifi and OpenWrt with correct configuration of hostapd.
So annoyed.
Dont use unit for routing, though.
Newly-registered domains are not generally an issue with enterprise users. However, they are overrepresented in malicious traffic due to domain-generation algorithms (DGAs).
I take it this means enterprise users are not generally needing to do anything legit-for-work on a newly registered domain.
Enterprise clicks on newly registered domains tend to be (a) being phished or smished or cryptomined or whatever, or (b) someone reading X or Bsky or HN or ProductHunt's vibe code of the date -- things the enterprise would also like to have blocked.
Consider the CloudFlare/Proofpoint/NextDNS/etc. domain block on new domains much like updating one's HN home page to https://news.ycombinator.com/classic …
it would be great if that could be in the article in the first place. (I'm assuming you are the author)
I did that for 5 different cameras yesterday, you're saying Unifi's cameras doesn't allow user management? That sucks!
> No, it connects to you!
I thought frigate connects to the camera's RTSP stream (maybe with ONVIF in the mix)?
For the adoption stage, UniFi cameras broadcast on UDP port 10001 using a proprietary TLV (Type-Length-Value) protocol. The Protect console listens on this port and picks up new cameras immediately. 4 bytes `\x01\x00\x00\x00` sent as UDP broadcast to `255.255.255.255:10001`
The response then contains these fields:
| 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) |
So conceivably at step 2 you could use your own modified URL to point to your own NVR and then grab the FLV streams from there.
> 1. Connects to the camera via SSH (default credentials) 2. Configures the Inform URL (TCP 8080)
Not what I expected but okay. Looks like there's a `set-inform` command. It looks like it opens a TLS connection, doesn't check the certificate, and tries to opens a websocket:
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
...then again I did a search for a couple strings and ran across https://github.com/keshavdv/unifi-cam-proxy . It's the opposite direction of what I want (makes a standard camera work with Unifi Protect) but maybe contains the protocol details I'm looking for...
Right, that's the expectation of Frigate, my own Moonfire NVR, and basically every other NVR out there. Ubiquiti decided to think different.
I think newer models like g4 flex dont support this thou.
Honestly it might be less work than some other cameras that (allegedly) speak RTSP. You'd be shocked how low-quality these implementations are. Never advancing timestamps, setting the RTP MARK bit arbitrarily, writing uninitialized memory framed as audio packets (on cameras that don't have microphones), closing file descriptors then writing data to them anyway (and so having it show up on the next accepted connection to be assigned that fd even pre-auth), etc.
Thanks for the reassurance that I'm not such an incompetent dev as I feel.
Funny how companies tend to be competent at either devices or software, and rarely both. This sounds vaguely like the automotive industry.
https://www.arecontvision.com/news/arecont-vision-adds-casin...
(eBay deal sniping sometimes gets you some funny deals but YMMV — I picked up an Axis Q1700-LE license plate camera for under $200 for some experiments.)
Vivotek's a bit more reasonable but still. The (brand new?) Vivotek VIT04A-W is the closest I've found—1/1.8" sensor, 4MP, turret, $535 on jmac.com.
These Ubiquiti models seem really nice in terms of hardware specs and and very reasonably priced. $200 for a 1/1.8" sensor turret, $479 for a 1/1.2" sensor turret with extra AI features. Same general price bracket as Dahua, I think.
Actually, yes. I got lazy and just asked Claude Code to write a server, using that as a reference...and it worked. It was able to change the password and have it start streaming flv video. Not exactly a production-quality implementation but as a proof-of-concept it's quite successful.
I'd like to make a production-quality version of what you're looking for: acts as an RTSP server, adopts Ubiquiti cameras. As a single-binary thing that you could run anywhere, maybe even on the camera itself. (self-adoption? emancipation, as in "emancipated minor"?) But it'll take me a bit. My RTSP library right now is client-only, so it needs a bit of expansion to do this. Server support is in my TODO list along with several other changes. https://github.com/scottlamb/retina/issues/89