Posts made by guero jose_338291415367917

@ks Son, I administer networks and systems for a living. If my explanations thus far don't give you a clear picture, I don't know what else to say. But thanks again for trying. Perhaps someone knowledgeable at Reolink will offer something, or better still give the customer actual access to the device that they purchased.

@ks @ks Yeah, I think you're getting confused with what I'm seeing. To simplify: The NVR has been given a static address and an 8-bit netmask. The only routing table that matters here is the one on the NVR: "Who's my gateway for sending packets responding to 10.2.2.200? Oh, ok, here you go.". It is the job of the other client systems to reach their own gateway vie their routing tables, which they do. It is the job of the nearest router/switch to deliver packets to the NVR, which it does. Again, other clients on both subnets can talk to each other just fine over the same network equipment, because they have a common vlan. Networks and routes on the client systems (whether Windows or Linux) are not being changed, and I can verify with Wireshark everywhere (except the NVR) that packets are routed correctly. It's the NVR that sees packets arrive from 10.2.2.200 and decides not to allow/respond, and we're not allowed to examine why not. But thanks anyway.

@ks But to clarify: Both office subnets are on a single VLAN, with network connectivity to each other. Other 10.2.2.0 systems can reach 10.1.1.0 systems, and vice versa. It's actually the NVR's routing table that seems to be the problem, but we aren't given the ability to examine that, ping from a CLI, etc.
Again, if the NVR is obeying the netmask that I'm defining (and the static IP address - DHCP does not enter into this), it should consider all 10.0.0.0 systems as local to its own LAN, and not be preventing connections.
P.S. Adding specific host IPs to the whitelist (not actually properly defined anywhere in the documentation) also has no effect.

RLN8-410 is on office network, using 10.1.1.100 netmask 255.255.255.0. Only hosts on that subnet can connect (app/browser) to the NVR IP, as expected. Second office subnet 10.2.2.0/24 hosts can't connect, as expected. But I should be able to change NVR netmask to 255.0.0.0 to allow the second subnet to connect. This would allow office users without opening up the system to whole-internet UID access.
Why doesn't netmask 255.0.0.0 behave as it should, and allow all local LAN 10.x.x.x clients to connect to the NVR?

How about a gel filter to block the visible red, but pass the NIR? Maybe somebody savvy can suggest a blue photo filter or something that could be applied over the camera, perhaps cut to a ring which blocks the LEDs but not the lens? This is definitely buyer's remorse-worthy, and something I wish I had seen earlier when reading up on Reolink before purchase.