Local Discovery not working with Reolink Battery Doorbell - is there a way to force it to use the same port?

[EricLauber]

This Product.

I would like to see if I can set neolink to run entirely locally without needing to connect to the internet. When I initially tried using local discovery and either used the camera UID or specified the IP address, neolink failed to connect to the camera.

If I let neolink connect using remote discovery, it gets a port number from Reolink and connects successfully. Great. I typed this port manually into my config file as in address = "MYIP:PORT" and local discovery started working. Awesome.

I'm just starting to learn neolink, so I shut it off yesterday and started it again today. It failed to connect to the camera using TCP and local discovery. I re-tried remote discovery and found that the camera port had changed dynamically.

That sort of puts a damper on being able to use local discovery. Is there a way to force this Reolink product to keep using the same port?

[QuantumEntangledAndy]

Put in the addr and the uuid into the config then set connection to local. Should work as long as you have a fixed ip for the camera

[QuantumEntangledAndy]

Could you send me the wireshark dump specifically I need to see that part about

The camera responds from (in this case) port 32956.

Perhaps the format is different for your cam and I need to update that part of the code

[QuantumEntangledAndy]

Wait your in a container. You can't use discovery in the container without using host mode (host mode only works on Linux)

[QuantumEntangledAndy]

The ip tables rules won't allow an unknown external port to map into the container.

[EricLauber]

Making progress!

I changed the docker-compose.yml to include network_mode: host instead of specifying ports. I'm currently testing using WSL2 for Windows so I also had to go into Docker Desktop to Enable host networking (which reset integration with my distro, weird).

This time local discovery locates the camera, but neolink fails to sign-in properly.

CAMERA_NAME: Local discovery success UID at 127.0.0.1:60579
CAMERA_NAME:  Connection Lost: Failed to login to CAMERA_NAME
    Caused by:
         deadline has elapsed

I then tested using the same docker-compose.yml on a Linux VM and it connected and logged in immediately using local discovery. This is likely how I would be using neolink long term, running in a docker container on a dedicated machine, so I think the network_mode: host is accomplishing the goal.

That said, when running in docker it can be preferrable to configure all ports an application would use. Maybe there's a way to specify what outgoing port neolink uses to talk to the camera?

[QuantumEntangledAndy]

It's a fundamental issue with how this type of NAT are navigated rather than an issue with docker per say. (Network address translation)

NATs work by forwarding networks across one host acts as a map from outside into inside. The outside machine (the camera) knows nothing about the inside network (the docker). The outside camera only sees the host.

What happens is something like this

• client sends packet to host from port (randomA) saying please forward this to camera on port 2018. Please send anything sent in reply back to me
• host opens a port on (randomB) to camera on port 2018. Host assigns random port to client remembering that if camera sends anything to port (randomB) from port 2018 I should forward it to (randomA) on client

This all works fine and it's how your switch is able to send data out into the internet for you

Now consider what the camera does

• after camera gets the connection on 2018 it thinks, "oh look host wants to talk to me I'll send a reply from (randomC) towards (randomB)". It's critical to note here that as far as camera is concerned there is no client, host is the client, it cannot see the network behind host.

• now host gets a reply from (randomC) to (randomB) but it has no idea where to send it. There can be any number of docker clients, which one should it go to? Host decides to just drop it.

Ways around this:

Now then the easiest way is host mode. Then the docker is also the host so it can see that push from (randomC) to (randomB)

More complex is to alter the docker setup to make a proper bridge.

In a bridge you share the interface (the wifi or Ethernet) the docker host gets its own ip on the host network (it will appear on the wifi network and you can ping it from anything on that network)

When you have a full bridge rather than a NAT the camera can now see client behind host. In fact as far as the camera is concerned there is no host client is it's own seperate machine on the network.

The issue with a proper bridge is that it's more complex to setup. You have to do it manually there's no magic button in docker for it. You loose some security and it requires that you trust your docker to be its own machine on the network.

[QuantumEntangledAndy]

Did some quick Googling you may also have some success if you swap the driver over to macvlan (again not windows)

https://docs.docker.com/engine/network/drivers/macvlan/