Forum Replies Created
Carl, thanks for confirming the use of broadcast packets.
Crimp On, you are one step ahead of me again 🙂
I was able to monitor some network traffic with Wireshark and came to the same conclusions from the above posts:
* When using the windows client software, it seems that the Flash player connects to the cameras on port 9000 and gets video from that connection.
* When the NVR is successfully communicating with a camera, it appears that the camera is the ”client” and the NVR is the ”server”. The NVR sends out some broadcast packets, and then the camera connects from its port 9000 to a random port on the NVR (which seems really weird).
The thing that was the most confusing to me about all of this is that when you are in the NVR's UI on the screen that lists out the cameras, you can click around in there and ”add” a new camera, including specifying the IP address and port. However, as far as I can tell, the NVR utterly ignores this. I never witnessed the NVR even attempting to send a packet to the camera that I tried to add using that IP field. It definitely appeared that the only way to get a new camera added was to get it on the same LAN so that it would respond to broadcast packets.
Once I convinced myself that the NVR was relying on broadcast, I set out on the adventure of configuring VLANs. (I have some Ubiquiti EdgeRouter X's that are capable of handling all of the necessary VLAN config.) Once I got all three cameras and the NVR on the same VLAN, I was able to add the third camera to the NVR with no problems. So, everything is working now; hooray!
In case some future reader is battling with this, the two key discoveries that were not obvious to me were:
* The Windows Reolink client establishes an outbound connection to the cameras, but the NVR is very different, and relies on broadcasting to the LAN to tell the cameras to establish inbound connections back to it; so your network topology and firewall rules need to allow for this.
* Even though the NVR has a place in the UI where it will let you type in the IP of a new camera, it does not appear to ever attempt a direct connection to that IP; it seems like it is impossible to successfully add a camera unless the camera can see and react to the broadcast packets from the NVR.
Thanks a bunch for your reply, that's very helpful. I know just enough networking to be dangerous 🙂 But I've been thinking about this problem solely from the Layer3 level. After your post, I read up on ARP and refreshed my memory on some Layer2 basics, and you're absolutely right. If I change the subnet mask on the Windows machine to 255.255.0.0 then I can no longer connect to the camera on 192.168.2.x.
So I'll change the NVR back to DHCP and that will set its subnet back to 255.255.255.0. Still need to figure out why it can't communicate with the camera. At present my only ideas are:
* Perhaps when the NVR first establishes the connection to the camera, it instructs it to make a new connection back to the NVR and they resume their communication over that socket. In that case my routing tables currently do not allow a connection to be established in this direction. Hoping to explore this by doing some wireshark with the cameras that are on the 192.168.1.x and seeing if I can determine how they interact with the NVR.
* I did some wireshark around the NVR already and I can see that it is sending out some broadcast/multicast packets. If that is an integral requirement for how the NVR and cameras communicate then it seems like I will have to make some major changes to my network topology, e.g. set up a VLAN for the NVR and cameras to share so that they can see eachother via broadcast.
Hopefully one of those two options will work; will update this post with any additional findings.
Thanks again for the pointers about ARP, Crimp On!
Do you know the technical details as to why the NVR can't add it? If I configure the NVR to have a static IP address and I set the subnet mask to 255.255.0.0, then as far as it knows, it *is* on the same LAN. And the windows client software works just fine.
Is the NVR doing some kind of broadcast packet that doesn't go outside of its LAN? Or does the camera have to be able to resolve the NVR's address and make a connection back to the NVR for some reason? Otherwise I don't understand why it won't work, because I know the IP address of the camera, I know that it is accessible from the LAN, and I know that the windows client software can interact properly with the camera from the LAN.