![]() In cases where the client is connecting to a Reolink DVR (digital video recorder) or NVR (network video recorder) instead of a camera, the wrapping XML element is instead of. Where 123456789 is the camera UID and MAC is the platform identifier of the connecting client. It also sends the same packet to the local broadcast address 255.255.255.255 of the local network which allows local cameras to respond, too: The client app sends a UDP packet from local port 16577 to port 9999 of with the following XML body (encoded using the algorithm mentioned above). It is likely that the camera sends regular UDP pings to the public P2P server to keep an active connection with the server to enable incoming connections. The actual magic happens through the dynamic port numbers allocated by the routers between both communicating parties and the ability to route packets back to the originating device by re-using those port numbers. The encoding uses a shared secret key and some additional transformations. The payload is encoded to avoid network address translation (NAT) layers changing the IP addresses included in the payload. The communication uses UDP packets with special payload that contain the information to establish direct connection between the client and the camera. This article by Bryan Ford is the best explanation of network hole punching for peer-to-peer (P2P) access. The Reolink client app uses the publicly accesible Reolink relay to establish a direct connection to the camera for remote management and video/audio communication. 123456789 is the Reolink UID (unique identifier) of the camera.15.237.112.14 is the IP address of the Reolink P2P server.is the hostname of the Reolink P2P server.6.0.0.1 is the public IP of the camera on the internet.196.0.0.1 is the local IP of the camera.7.0.0.1 is the public IP of the app on the internet.10.0.0.1 is the local IP of the app connecting to the camera remotely.In the description bellow we’ll use the following addresses and names to describe the network participants: The decoding of their proprietary packets was possible thanks to the Baichuan/Reolink proprietary IP camera protocol dissector for Wireshark bundled with the camera_proxy project. I used the version 8.2.6 of the Reolink client for MacOS (which is an Electron app) and Wireshark to capture and decode the traffic between the software and the internet. Based on this research by Nozomi Networks Labs and the camera_proxy project, I’ve been able to capture and inspect the communication protocol used specifically by the Argus 3 camera. Update: The protocol is now well understood and supported by the Neolink RTSP bridge software and this fork of the Camera Proxy project.īattery powered cameras from Reolink offer remote viewing and management even when cameras are behind mobile network data connections. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |