Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Reverse-engineering the UniFi inform protocol

tamarack.cloud

Post reply on HN
Print view View original

51–60 of 81 posts

Re: Reverse-engineering the UniFi inform protocol

#51

Post by scottlamb »

scottlamb wrote: post #48
moonlighter wrote: post #38

Earlier quoted context omitted.

Unifi cams don't stream RTSP, they stream FLV v1 (FlashVideo) on 3 streams over plain TCP on port 7550, one per quality channel. And yes, they stream that TO the NVR who adopted them only... then the NVR recodes and sends RTSP (configurable). 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…

Thanks! > 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: we…

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

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.

Re: Reverse-engineering the UniFi inform protocol

#52

Post by Szpadel »

baconomatic wrote: post #21
CptKriechstrom wrote: post #19

Earlier quoted context omitted.

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

We support two approaches, you can either pre-register MAC-Addresses or you can add source IP's to assist with that mapping. There is more information in our docs about this: https://tamarack.cloud/docs/migration

that's the key information to understand the whole thing.

it would be great if that could be in the article in the first place. (I'm assuming you are the author)

Re: Reverse-engineering the UniFi inform protocol

#53

Post by baconomatic »

Szpadel wrote: post #52
baconomatic wrote: post #21

Earlier quoted context omitted.

We support two approaches, you can either pre-register MAC-Addresses or you can add source IP's to assist with that mapping. There is more information in our docs about this: https://tamarack.cloud/docs/migration

that's the key information to understand the whole thing. it would be great if that could be in the article in the first place. (I'm assuming you are the author)

Good call, I should have made that more clear. Article updated!

Re: Reverse-engineering the UniFi inform protocol

#54

Post by scottlamb »

ImPostingOnHN wrote: post #33
scottlamb wrote: post #32

Earlier quoted context omitted.

> I thought frigate connects to the camera's RTSP stream (maybe with ONVIF in the mix)? Right, that's the expectation of Frigate, my own Moonfire NVR, and basically every other NVR out there. Ubiquiti decided to think different.

Well thanks for the heads-up to avoid their cameras.

I hear you, but on the other hand, I'd take a bit of interop pain over supporting genocide any day. It looks like with the hints from moonlighter and from https://github.com/keshavdv/unifi-cam-proxy I'll be able to get this to work.

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.

Re: Reverse-engineering the UniFi inform protocol

#55

Post by BenjiWiebe »

blacklion wrote: post #49
myself248 wrote: post #36

Earlier quoted context omitted.

Alternately, run OpenWRT on the APs themselves, and then you just need one provisioning protocol.

Does it support seamless roaming of clients between group of APs? Last time I've tried, it was not supported by any open source solution.

Well AFAIK the core seamless roaming in Unifi is using hostapd, which is the same AP software you use on OpenWrt. See 802.11r Fast Transition.

I think it should even be possible to get seamless roaming between Unifi and OpenWrt with correct configuration of hostapd.

Re: Reverse-engineering the UniFi inform protocol

#56

Post by gh02t »

roywashere wrote: post #40
baconomatic wrote: post #27

Earlier quoted context omitted.

It would definitely be simpler, however the routing issue still stands. You would need to have a public IP for every VM, which is getting less practical. The MAC-based proxy makes it so we only need one IP and we can worry about the routing within our platform instead.

but it is http! why can't you do virtual hosting on a reverse proxy?

You can after the initial discovery step, the article mentions this. The MAC routing is for the first step where the device is reaching out to try and find a controller and signal it's available for adoption, which uses an IP address at least in the scheme that is relevant for hosted operators. After that initial channel is established, the controller uses it to tell the device what its hostname is, and you can switch to more normal HTTP proxy routing thereafter.

Re: Reverse-engineering the UniFi inform protocol

#57

Post by andrewaylett »

burgreblast wrote: post #50
andrewaylett wrote: post #47

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 nec…

I don’t get this comment. Inspection does work but the suggested alternatives don’t. 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 solut…

The author framed his issue as a choice between separate VMs (with high cost) per user or decoding the messages. As he, you, and I all say: what he's got does work. I'm absolutely not saying that now he's solved the problem he should do something else. But the choice wasn't between only those two extremes.

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.

Re: Reverse-engineering the UniFi inform protocol

#58

Post by baconomatic »

gh02t wrote: post #56
roywashere wrote: post #40

Earlier quoted context omitted.

but it is http! why can't you do virtual hosting on a reverse proxy?

You can after the initial discovery step, the article mentions this. The MAC routing is for the first step where the device is reaching out to try and find a controller and signal it's available for adoption, which uses an IP address at least in the scheme that is relevant for hosted operators. After that initial channel is established, the controller uses it to tell the device what its hostname is, and you can switc…

Yep, that's exactly right!

Re: Reverse-engineering the UniFi inform protocol

#60

Post by baconomatic »

stereo wrote: post #59

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

Yeah IPv6 would solve this because we wouldn't have to go through the proxy at all, since each VM could get their own. Unfortunately IPv6 isn't quite as supported as we'd like.
Post reply on HN