3D camera not pingable on a Linux controller: fix subnet and link

The green and amber port LEDs hold steady, the cable is new, and ping still prints 100% packet loss. That combination almost never means a broken camera: the fault sits above the cable, in addresses, routes or firewall rules. It is findable in ten minutes with five commands. This guide is for integrators connecting Ethernet 3D cameras — laser profilers, stereo and structured-light 3D sensors — to controller-class Linux hosts. You will finish with both ends on matching static IPs, for example controller 192.168.1.10/24 and camera 192.168.1.20/24, plus a five-command pass you can re-run any time a camera goes quiet.

Why is my 3D camera not pingable from a Linux controller?

Because link LEDs certify only the Ethernet physical layer, while ping needs an IP address in the camera's subnet on the right NIC, a route that leaves through that NIC and a firewall that does not drop ICMP; the fault is usually on the controller side, not in the cable.

Work the causes in this order, because that is how often each turns up on the bench:

1. The camera is not at the address you think: it was reset, moved, or left in DHCP mode and took a new subnet.
2. The controller NIC facing the camera has no address in that subnet, typically a second port that was never configured.
3. Ping leaves through the wrong NIC: a second default route or a broader network route wins the lookup.
4. The controller firewall drops inbound ICMP, or everything new, on that interface.
5. The camera's own network stack is genuinely ill — rare, and the final section gives it a fair test.

Steady port LEDs alone move cause 5 to last place: a PHY that links and a stack that answers ARP are different machines.

What do steady link LEDs on the port actually prove?

They prove the physical layer settled: cable pairs, autonegotiation and 1000BASE-T clocking between the two PHYs, typically within a second or two of plugging in — and they prove nothing above it.

Addresses, netmasks, ARP, ICMP and firewall rules all sit above the LED layer, which is exactly where this fault lives. The terminal confirms the LED story: sudo ethtool enp3s0 ends with Link detected: yes and the negotiated speed. A dark LED, or a port negotiating 100 Mb/s on Gigabit gear, points at power, cable pairs or the PHY itself; a healthy link with a silent camera points upward, at IP. One LED cannot tell you whether the camera holds 192.168.1.20 or fell back to a 169.254.x.y address — and that difference decides everything that follows.

Which addresses must match for ping to work?

With the usual 255.255.255.0 (/24) mask, controller and camera must agree on their first three octets: controller 192.168.1.10 and camera 192.168.1.20 share the network 192.168.1.0, so ARP succeeds; a camera at 192.168.0.20 sits in 192.168.0.0 and ping dies on a perfect cable.

The test is a logical AND of each address with the netmask:

A mismatched pair has a signature. The controller finds no local route for the camera, forwards the probe toward its default gateway, hears nothing useful, and answers itself with Destination Host Unreachable. It looks like a dead camera; it is a routing verdict. A matched pair replies in well under 1 ms on a direct link. A /24 holds 256 addresses, 254 of them usable, which is ample for one camera cell and keeps the arithmetic visible at a glance.

What to run on the Linux controller to find the fault

Run five commands in this order — ip -br addr, ip route get, ping -c 4, ip neigh show and ethtool — and each clears one layer of the fault; the whole pass takes under a minute. The examples use enp3s0 as the camera-facing NIC and 192.168.1.20 as the camera address; substitute yours.

1. ip -br addr prints one line per interface with link state and addresses. The camera's subnet must appear on exactly one NIC, for example enp3s0 UP 192.168.1.10/24. A port that is UP with no address, or a 10.x address where the camera wants 192.168.1.x, is the fault found.
2. ip route get 192.168.1.20 shows which interface and source address the kernel would actually use. 192.168.1.20 dev enp3s0 src 192.168.1.10 is correct; a different interface, or a line containing via, means a route is stealing the packet.
3. ping -c 4 192.168.1.20 sends four probes. Four replies under 1 ms close the network case. Repeated Destination Host Unreachable sourced from the controller's own address means ARP found no listener.
4. ip neigh show prints the neighbor verdict: REACHABLE proves the IP path and moves the hunt to SDK discovery; FAILED means no ARP answer, so the fault is address, subnet or camera; STALE is an old entry waiting for traffic.
5. sudo ethtool enp3s0 confirms what the LEDs claimed: Speed: 1000Mb/s and Link detected: yes close the physical case for good.

How to set the camera's IP when the controller cannot run the vendor tool

Configure the camera once from any ordinary PC that runs the vendor's viewer or IP configuration utility: connect the camera to that PC, set a static address in the controller's subnet — 192.168.1.20 with mask 255.255.255.0, against a controller NIC at 192.168.1.10/24 — then move the cable back; the camera keeps that address across power cycles.

Controller-class and embedded hosts often cannot install a desktop viewer: a different processor architecture, or no desktop at all. That does not block the fix, because the PC acts as a one-time programmer and the camera stores the setting itself. Set the mask to 255.255.255.0, leave the gateway empty on a direct link, save, power-cycle the camera, and re-run the five-command pass on the controller. A camera left in DHCP mode with no server on the wire carries a 169.254.x.y link-local address instead — that number in your notes is the signature, and the static set above is the fix.

Can the controller's firewall or its routing table block ping?

Yes: a default firewall that drops inbound ICMP silences a healthy camera, and a second default route can send the ping out of a NIC the camera is not on — both faults live on the controller and both survive a perfect cable.

Factory and controller images frequently ship with a firewall enabled, so a fresh install can be the very change that quieted a working cell. Give it a one-minute test window: set the camera-facing interface to a fully trusted zone or stop the firewall service, ping again, then restore the firewall and add scoped accept rules instead — ICMP to the camera's subnet on that interface, plus the UDP ports the SDK discovers on. The port and rule pattern for controller-to-PLC traffic applies unchanged, and ping works, discovery fails is the same fault one layer up. If step 2 above named a different interface, delete the broader route rather than stacking exceptions.

Ping works but the SDK cannot find the camera — why?

Because discovery and ping travel different roads: most machine-vision SDKs find cameras with broadcast or subnet-scoped UDP packets, which firewalls drop and which never leave the local subnet, so a camera one subnet away can answer ping through a fluke route yet stay invisible to the tool.

Three checks close it. Bind the SDK to the camera-facing NIC, because multi-homed hosts often default to the first interface and discovery probes only that one. Confirm the camera's subnet equals that NIC's subnet — the AND test from the addressing section, applied to the interface the SDK is using. Allow UDP on that interface in the firewall you just scoped. Why GenICam discovery uses subnet broadcast walks the broadcast mechanics end to end, Linux discovery troubleshooting collects the Linux-side checks, and the 3D vision topic page gathers the rest of the family.

When is the camera itself the fault?

You may accuse the camera only when four facts hold together: Link detected: yes at both ends, matching subnets proven by the AND test, a clean ip route get, and ip neigh show still printing FAILED with the firewall off for the test window — that combination points at the camera's network stack.

Work it in three moves. Power-cycle the camera and re-run the pass. Apply the vendor's factory-network reset exactly as its documentation presents it. Then try the camera from a bench PC, where it should answer ping at whatever address it holds. A camera that answers on the bench but not on the controller, after a clean five-command pass, is a controller problem in a camera costume. A camera that stays silent everywhere with LEDs lit has earned its warranty case — start it through the contact page. None of this applies to a USB-connected 3D camera: that failure is kernel enumeration, not IP. A UVC camera the kernel does not recognize follows its own repair path, and so does a depth camera with a black image over USB.

How to specify the next cell so this fault cannot return

Design it one-camera-one-NIC: each Ethernet 3D camera gets its own controller port and its own /24, so 192.168.10.x, 192.168.20.x and 192.168.30.x never touch each other and a moved cable changes nothing. Hold every link to the standard 1500-byte MTU unless the whole path is proven for jumbo frames — a mixed-MTU path breaks streams, not ping.

Size the host by port count first, with one port to spare. In the vision controller range, three hosts cover most cells. The MV-VC2140-128G40-1T provides 3-4 LAN ports around an Intel N-series processor. The MV-VC3301H-128G66 provides 5+ LAN ports, 8 GB memory and PCIe expansion, with no PoE. The MV-VC5525-256G70-NN provides 5+ LAN ports, PoE camera ports, 8 built-in light channels and 32 GB memory.

Then bolt the prevention list to the panel door:

• One subnet per NIC, cameras off the PLC and office network — an overlap can silently drop two devices at once.
• Static IPs on both ends, any DHCP pool placed outside the static range — a power cycle then changes nothing.
• Scoped firewall accepts per camera subnet, restored after every test window — ping and streams pass; the cell stays closed otherwise.
• The IP map taped inside the door — NIC name, subnet, camera address — turns a recurrence into a two-minute fix.

The next fault on a now-healthy link is throughput: a subnet that passes ping can still choke a 3D stream, and the network-path checks in 3D camera image latency: fix subnet and network path pick that up in minutes.

To choose the host itself, the vision controllers category lets you filter by LAN port count, PoE and memory. In-stock items ship within one business day, and the applications team answers set-up questions with every order — bring the ip neigh output if a case survives the five-command pass.