Connect a camera on a different subnet without adding a second IP

Your 3D camera sits behind a robot controller, a cell router or a VPN. Ping works, a TCP test to the camera's control port works, and discovery still lists the camera — yet the SDK refuses to open it, reporting that the camera's IP is not in the subnet of any of your adapters. On a flat network that check catches real wiring mistakes; across a deliberate routed link it is a false block. This guide shows the two-file fix: a Cameras.yml host entry that names the camera by IP, and a Config.yml switch that turns multicast discovery off, so the SDK connects directly and skips the pre-check. It applies to 3D sensors and GigE area scan cameras alike and takes about ten minutes once the route exists.

Why does the SDK refuse a camera that pings fine?

Because the SDK never tries the connection: it discovers the camera by multicast, then checks whether the camera's IP falls inside a subnet one of your adapters actually holds, and refuses to open TCP when it does not.

The check compares network addresses, not reachability. The camera's IP ANDed with its mask must land inside a network that one of your adapters also holds. 172.24.2.20 on a /24 lands in 172.24.2.0; a laptop address of 172.24.1.101/24 lands in 172.24.1.0. No match, no connection attempt — the SDK reports the camera unreachable before the first packet of the session is sent.

So why did discovery list the camera at all? Multicast discovery still found it because an mDNS repeater on the boundary host relayed it. Ping and TCP succeed because routing is in place, which is why this failure feels like a bug. On a flat, switched network the same check catches wrong netmasks and duplicated addresses, so it stays the default. Cameras of this class — the MIS-DP3850-01P is a 3D laser profile sensor — meet it on mobile robots and remote cells, where a second subnet is deliberate.

What is the documented fix for a camera on a different subnet?

The documented path is two small YAML files in the SDK's per-user configuration directory: a Cameras.yml host list that names the camera by IP, and a Config.yml switch that turns multicast discovery off, so the SDK connects directly and skips the same-subnet pre-check.

Normal discovery rides on subnet broadcast, which a router will not forward and a VPN tunnel will not carry. Unicast discovery is the alternative for devices outside the host's subnet: the request goes to one known IP, and the reply carries what a broadcast would have returned. The connection that follows needs no subnet match. SDKs expose this as a configuration-file feature rather than an API argument, which is why it is easy to miss. Use the two files together: the host list supplies the address, and the discovery switch is what changes how the connection is made.

What goes in Cameras.yml and Config.yml?

Cameras.yml carries one NetworkCamera entry per camera with a Host key holding the camera's IP, and Config.yml sets DisableMDNSNetworkDiscovery to yes; both files start with a __version__ header and live together in the SDK's API folder under your user's configuration directory.

On Linux that means a folder under .config in your home directory — the SDK's manual names the exact parent folder for your installed version; create it if it does not exist. Cameras.yml, one entry per camera:

__version__: 1
Cameras:
  NetworkCameras:
    - NetworkCamera:
        Host: 172.24.2.20

Config.yml, the switch that sends the SDK down the direct path:

__version__: 20
Configuration:
  BackwardsCompatibility:
    DisableMDNSNetworkDiscovery: yes

The __version__ lines are part of each file format; copy them as your SDK's documentation shows them for your version. Restart the viewer or your application after writing the files so they are read again.

Which steps connect the camera end to end?

Seven steps take a routed-but-refused camera to a working capture: pin the camera's address, confirm the route, ping it, test the control port with TCP, write the two files, restart the SDK, and capture one frame before scripting anything against the camera.

1. Pin the camera's address: a static IP on its own subnet (172.24.2.20/24 in this example) or a DHCP reservation, so the host entry stays valid across reboots.
2. Confirm the route: ip route must list 172.24.2.0/24 via 172.24.1.2; if it does not, add it with sudo ip route add 172.24.2.0/24 via 172.24.1.2.
3. Ping the camera: ping -c 4 172.24.2.20. Four replies prove the routed path carries traffic.
4. Test the control port: nc -vz 172.24.2.20 52811 returning succeeded proves the SDK's TCP path end to end. 52811 is this SDK family's port in the example; your SDK's logs print the port it targets.
5. Write Cameras.yml with that exact IP under Host, as shown above.
6. Write Config.yml with DisableMDNSNetworkDiscovery set to yes.
7. Restart the viewer or application and open the camera: it should enumerate from the host entry and capture.

You know it worked when the viewer lists the camera with no subnet warning and a full frame comes back. If it still refuses after a pass on step 4, the files are not being read — check the folder, the owning user, and the file format against your SDK's manual before touching the network again.

Common mistakes: writing only Cameras.yml and expecting the pre-check to disappear (the discovery switch does that), leaving a live DHCP lease in Host, and testing from one account while the application runs as another.

What does the routed set-up look like end to end?

Three addresses decide this example: the camera at 172.24.2.20/24 on the robot's camera subnet, the robot host bridging that subnet to Wi-Fi at 172.24.1.2/24 with IP forwarding on, and your laptop at 172.24.1.101/24 holding one static route via 172.24.1.2.

The subnet test the SDK performs, with the arithmetic shown:

Routing still delivers the packets: 172.24.2.20 falls inside 172.24.2.0/24, so the laptop's longest match sends the traffic to 172.24.1.2, and the robot host forwards it onto the camera subnet. Discovery reached the laptop only because the mDNS repeater relayed multicast between the two networks. The addresses change from site to site; the pattern does not, and any GigE Vision camera follows it — the MV-CU020-90GC is a 2.5 MP GigE area scan camera.

Does the same fix work over a VPN?

Yes — the host entry removes the multicast dependency that VPN tunnels rarely carry, so the SDK opens a plain TCP session to the camera's VPN-side address; the same two files apply unchanged, with Host set to that address.

Tunnels pass unicast well and multicast poorly or not at all, which is exactly the split that produces this failure: discovery messages vanish, while a direct session through the tunnel behaves like any other TCP client. Two things do change on a tunnel: round-trip time goes up and the largest safe packet often goes down, so large 3D frames can hit capture timeouts even though the connection is healthy. If captures come back late or truncated, diagnose the path the same way you would on a wired routed link — the subnet and network-path latency fix for a depth camera is that diagnosis written out.

When should you not run a camera across a subnet boundary?

Keep production pixel streams off routed and wireless hops: GigE Vision video rides on UDP with no retransmission, so a router or radio dropping even one packet in a thousand appears as torn frames and dropped points, never as an error.

A wired gigabit hop carries roughly 110 MB/s of useful payload — 1 Gbit/s of line rate is 125 MB/s, and UDP plus protocol overhead take the rest. A Wi-Fi link shares its airtime with every other device on the network and retransmits at the radio layer, so both the average rate and the timing consistency degrade exactly where a 3D camera needs them steady. The vendors behind these SDKs say it plainly: connect the camera directly or through a switch. Route commands, not pixels. A vision controller mounted in the cell owns the camera subnet locally and hands the plant network only results over TCP. The MV-VC3301H-128G66 has 5+ LAN ports and 4 built-in light channels, so camera networks and the uplink stay separated by construction.

What else stops a routed camera from connecting?

Check four usual suspects before the SDK itself: a firewall eating discovery or the control port, a duplicate camera IP on the camera subnet, a DHCP lease that moved the camera, and two adapters of yours sharing one subnet.

• Firewall. Discovery replies and the TCP control port must both pass the host firewall. The firewall diagnosis for GigE Vision cameras covers the ping-works-discovery-fails signature.
• Duplicate addresses. Two cameras holding one IP on the same subnet refuse connections outright; give each camera its own address before debugging anything else.
• DHCP drift. A renewed lease moves the camera off the address in Cameras.yml. Reserve the address or go static — the DHCP blocker for a 3D camera firmware update shows the same trap in another workflow.
• Two adapters, one subnet. Discovery can bind to the wrong interface and enumerate doubled or absent cameras; the two-adapters-on-one-subnet hang is that trap from the other side.

When the camera lives on a robot cell, the wider integration questions — cabling, mounting, controller hand-off — are covered in the 3D camera robot integration checks. Routed-address discipline reaches beyond cameras too: when a plant HMI or controller moves subnets, the same explicit re-addressing applies, and reconnecting an HMI terminal to a different subnet walks one such case.

What should you check before relying on this in production?

Confirm four things once and the set-up survives reboots: the host files under every account that runs the SDK, a persistent route, a fixed camera address, and a loss-free test across the boundary host before you trust it with captures.

• Host files per account: both YAML files present in the config directory of each user that launches the SDK, service accounts included.
• Persistent route: the ip route add from step 2 dies at reboot; make it permanent in your distribution's network settings.
• Fixed camera address: static or reserved, matching Host exactly, re-checked after a camera power cycle.
• Path quality: 100 pings across the boundary host with zero loss is a reasonable bar for capture work; a wired gigabit hop passes it easily, a busy Wi-Fi link often does not.
• Rollback plan: if the routed hop degrades captures, the fix is topological — direct Ethernet or a local switch in the cell — not more configuration.

Run the decision in this order: route, ping, TCP test, two files, capture. A passing TCP test plus an SDK refusal means write the files; a failing TCP test means fix the network first, because no file changes a path that does not exist. When the camera belongs in the cell permanently, pick it with the 3D sensor finder — the same finder filters GigE area cameras — and keep the capture local with a vision controller.