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

21–30 of 81 posts

Re: Reverse-engineering the UniFi inform protocol

#21

Post by baconomatic »

CptKriechstrom wrote: post #19
baconomatic wrote: post #16

Earlier quoted context omitted.

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?

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

Re: Reverse-engineering the UniFi inform protocol

#22

Post by bastawhiz »

paulddraper wrote: post #14
ctippett wrote: post #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 unsup…

What does an admin do about NextDNS blocks?

If you subscribe to the mindset of "new domains are likely to be bad" you just deal with a steady stream of allowlist requests from your users until the end of time. There will be new domains until the end of time, and site owners shouldn't be doing anything extra (imo) to justify their existence to admins. If you use a firewall voluntarily and that firewall blocks sites that are legitimate, that's on you, not the site owner.

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.

Re: Reverse-engineering the UniFi inform protocol

#24

Post by mikepurvis »

EvanAnderson wrote: post #8
idorosen wrote: post #7

Earlier quoted context omitted.

Using the network byte ordering (big endian) of UBNT as the magic number in the protocol is a nice touch.

I believe they used MIPS processors in their early gear, so that makes sense.

A lot of companies in that space did then. I was at a robotics company at the time and we experimented with mikrotik routerboards + the various long-range Ubiquiti wifi modules, some of which are even still listed on the website: https://techspecs.ui.com/uisp/accessory-tech/xr (though not the 900 MHz XR9, which was arguably one of the most interesting for long range comms)

Re: Reverse-engineering the UniFi inform protocol

#27

Post by baconomatic »

bxbdbehdbdb wrote: post #26

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?

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.

Re: Reverse-engineering the UniFi inform protocol

#28

Post by ImPostingOnHN »

scottlamb wrote: post #10

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

If you want to bypass Unifi Protect, what sort of "adoption" are you thinking of? AFAIK, "adoption" is a Unifi Protect thing. Otherwise it's just a device on your network that you can configure Frigate etc. to connect to and pull streams.

Re: Reverse-engineering the UniFi inform protocol

#29

Post by adobrawy »

ctippett wrote: post #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 unsup…

How are you performing backup of FerratDB? Are you using MongoDB tools, or are you using PostgreSQL-specific tools?

Re: Reverse-engineering the UniFi inform protocol

#30

Post by scottlamb »

ImPostingOnHN wrote: post #28
scottlamb wrote: post #10

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

If you want to bypass Unifi Protect, what sort of "adoption" are you thinking of? AFAIK, "adoption" is a Unifi Protect thing. Otherwise it's just a device on your network that you can configure Frigate etc. to connect to and pull streams.

Changing the credentials for web access (firmware upgrade, janky jpeg-based live stream, etc.) and ssh access from the default ubnt:ubnt. Surprisingly, I don't see a page for this in the web UI, and the `password` command in the CLI is ineffective. I haven't looked around the filesystem.

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!

Post reply on HN