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.
Reverse-engineering the UniFi inform protocol
71–80 of 81 posts
Re: Reverse-engineering the UniFi inform protocol
#72Earlier 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.
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.
Re: Reverse-engineering the UniFi inform protocol
#73It 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
#74Re: Reverse-engineering the UniFi inform protocol
#75Earlier quoted context omitted.
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…
FWIW, there are multiple other camera brands who don't manufacture in Xinjiang (or China for that matter), like Axis or Vivotek.
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.)
Re: Reverse-engineering the UniFi inform protocol
#76"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 ?
Re: Reverse-engineering the UniFi inform protocol
#77Earlier quoted context omitted.
Ubiquity in general has had garbage support for IPv6 since the beginning. They claimed most of their customers aren't asking for it when I pushed them on the issue years ago.
Yup, absolutely. I'm so annoyed by this. I haven't been able to get either my Comcast IPv6 address pool set up and usable throughout my home network (three switches and two Unifi Pro 6 WAPs, across a few VLANs), nor my HE.net tunnel. So annoyed.
Dont use unit for routing, though.
Re: Reverse-engineering the UniFi inform protocol
#78Earlier quoted context omitted.
> ...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 h…
There you go! I wrote a proxy server to deal with Unifi cameras and also dewarp their 360 camera streams... and used Claude Code to reverse-engineer most of what's going on. Sniff the entire network traffic between their NVRs and cams via Wireshark/TShark, grabbing the NVR's web socket streams, and also had it write a custom METAL shader pipeline native to Apple silicon to replace ffmpeg which was way too slow to dea…
Re: Reverse-engineering the UniFi inform protocol
#79Earlier quoted context omitted.
There you go! I wrote a proxy server to deal with Unifi cameras and also dewarp their 360 camera streams... and used Claude Code to reverse-engineer most of what's going on. Sniff the entire network traffic between their NVRs and cams via Wireshark/TShark, grabbing the NVR's web socket streams, and also had it write a custom METAL shader pipeline native to Apple silicon to replace ffmpeg which was way too slow to dea…
I actually just registered here to comment the first time after lurking for years ;) I had the displeasure to upgrade from a broken g3 flex to a g5 flex, and then finding out they cut out the rtsp stream functionality for unknown (probably business) reasons. I dont plan to buy a protect appliance, and frigate should still handle my nvr stuff, so this comment thread comes really handy right now. Is there any possibili…
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
Re: Reverse-engineering the UniFi inform protocol
#80"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 ?