Find a DHCP camera's IP address after every reboot

A camera on a managed plant network lives by the lease: static addresses are forbidden, the DHCP server hands out whatever is free, and the address that worked yesterday does not answer today. If you run a 3D camera or a 2D camera under that policy, here is the whole path in one place: find the current address from any Linux host with mDNS, read why the connection still times out anyway, move the camera onto the host's subnet with its own DHCP client mode, and automate the lookup so every boot resolves the camera without a configuration tool.

Why does the camera vanish from the network after every reboot?

It never vanished: in DHCP client mode the camera asks the plant DHCP server for a lease at every boot, and once its previous lease has expired the server is free to hand that address to another device and offer a different one.

DHCP servers usually try to re-award the same lease to the same hardware, but nothing in the protocol guarantees it after expiry, and lease times on plant networks run anywhere from minutes to days. An address that survived ten reboots can still change on the eleventh, so treat the camera's address as a runtime fact rather than a configuration constant. There is a second trap behind the first: the camera can boot onto a subnet your host does not share at all — alive on the link, announcing itself, yet invisible to every scan you run from the workstation. The next section explains why that scan comes up empty.

Why does arp-scan never list the camera?

arp-scan can only interrogate hosts on the interface's own subnet, because ARP requests are Layer-2 frames that routers do not forward, so a camera announcing an address outside your network is invisible to it by design.

Suppose your interface enp59s0 holds 10.50.102.24/24. The scan then covers 10.50.102.1 through 10.50.102.254 — one ARP request per candidate address, nothing else. A camera announcing 192.168.0.69, a factory-default style address on a different network, simply never hears the question. The camera is not absent; it is answering on a subnet you never asked. That mismatch, not the scan itself, is the fault to fix, and the discovery method below sees straight through it.

How do I find the camera's current address without a vendor tool?

Let the camera announce itself: mDNS records ride the local link as multicast, so the avahi-browse command on a stock Ubuntu host prints the camera's current address even when that address sits on a subnet the host cannot route to.

1. Confirm the mDNS daemon is running: systemctl status avahi-daemon (Ubuntu installs it by default on the desktop image).
2. Browse resolved entries and filter on the Workstation service (_workstation._tcp) that this class of 3D cameras registers: avahi-browse -arp 2>/dev/null | grep -i workstation
3. No hit? Run avahi-browse -arp without the filter — -a lists every service on the link, -r resolves them, -p prints one parseable line each — and spot the instance name that carries your camera's MAC.
4. Read the address from field eight of that line, then ping it once the subnets match (two sections down).

On macOS the built-in dns-sd tool browses the same records; on any other OS, a DNS-SD browser follows the identical pattern. Not every camera registers the Workstation type, which is exactly why step 3 drops the filter.

How do I read the avahi-browse line?

Split the resolved line on its semicolons: field eight is the address you want and field nine is the announced service port, so one grep gives you the camera, its hostname and its location on the network.

=;enp59s0;IPv4;cam-40-2f-75;Workstation;local;cam-40-2f-75.local;192.168.0.69;9;

Take field eight and let the SDK handle the port: the announced value belongs to the advertised service, not to the API endpoint, and the camera behind this example answered on the SDK's default port while its announcement kept saying 9.

Why does discovery find the camera but the connection still time out?

Because discovery needs no route while a session does: mDNS arrives as link-local multicast, but the TCP connection your SDK opens must cross the subnet, and a camera at 192.168.0.69 is unreachable from a host interface at 10.50.102.24/24.

Host interface    : 10.50.102.24/24            (ip -4 addr show enp59s0)
Network           : 10.50.102.24 AND 255.255.255.0 = 10.50.102.0
Reachable range   : 10.50.102.1 - 10.50.102.254
Camera (field 8)  : 192.168.0.69
Membership test   : 192.168.0.69 is not inside 10.50.102.0/24
Result            : no route to the camera -> ping fails -> the SDK times out

That is the full signature: the browse prints a healthy line, ping returns nothing, and the SDK reports an XML-RPC or socket timeout — often with the tool itself asking whether you can ping the sensor. Nothing is broken; the two ends sit on different networks. When a configuration tool pops a dialog offering to change the camera's address to match yours, that rewrite is why the camera works right after the tool touches it: the change lives in the camera's runtime, and the next reboot hands the address back to whatever the camera's own network mode says. So the durable fix sits in the camera's network settings, not in the scan. If ping fails after the subnets do match, the subnet and link checklist for a 3D camera on a Linux controller walks the remaining causes, from NIC state to cable.

How do I stop hunting for the address after every reboot?

Enable the camera's own DHCP client mode so it leases from the same server as your host: the camera then always lands on the plant subnet, and the address discovery finds is the address the SDK can reach.

1. Open the camera's network configuration — its web page or the network section of the configuration tool.
2. Switch the address mode from the factory default to DHCP client, so the camera leases from the same server as the workstation.
3. Reboot the camera and re-run the browse: field eight now falls inside 10.50.102.1-10.50.102.254.
4. ping the new address, then open the SDK session to confirm the whole chain.
5. If a firewall rule or an operator screen needs one stable value, ask the network team for a DHCP reservation that pins the camera's MAC to one leased address; the camera stays in DHCP mode and the address stops moving.

With avahi running you can drop addresses from your configuration entirely: field seven's hostname resolves on any avahi host, so the config file can hold cam-40-2f-75.local and the name follows the camera through every new lease. For the server side — setting the mode and running one DHCP server for a 3D camera — see DHCP for a 3D camera: set the mode and run one server, and if a camera forgets a configured address across a power cycle, the persistent-IP-after-reboot checklist covers that separate fault.

Does a second network port on the controller solve it?

Yes, and it is the cleanest architecture when plant policy is fixed: the controller's uplink port rides the managed DHCP network, while the cameras hang off a private second NIC with a small fixed plan the plant network never sees.

It is the standard layout for a multi-camera cell: NIC 1 obeys the lease policy on the plant VLAN, NIC 2 gives each camera an address that never changes, and no mDNS is needed on the camera link at all. The vision controllers below carry enough ports for both worlds. The MV-VC3301H-128G66 and the MV-VC5525-256G70-NN both list 5+ LAN ports, and the MV-VC5525-256G70-NN adds PoE camera ports, so a PoE camera draws power over the link without an injector.

On the private NIC the discovery problem disappears by construction: a small fixed subnet, deterministic addresses, and the plant network never sees a camera. Keep the uplink honest — DHCP client there, static nowhere on the managed side — and both policies hold at once.

How do I automate the lookup in Python?

The zeroconf package browses the same mDNS records from Python, so a listener started before your acquisition loop returns the camera's instance name and leased address without any vendor library or manual step.

from zeroconf import IPVersion, ServiceBrowser, Zeroconf

SERVICE_TYPE: str = "_workstation._tcp.local."   # service this camera class registers
NAME_PREFIX:  str = "cam-"                       # instance-name prefix of your units
found: list[tuple[str, str]] = []                # (instance name, IPv4 address)

class CameraListener:
    def add_service(self, zc: Zeroconf, type_: str, name: str) -> None:
        info = zc.get_service_info(type_, name)
        if info and name.startswith(NAME_PREFIX):
            for addr in info.parsed_addresses(IPVersion.V4):
                found.append((name, addr))

zc = Zeroconf()
ServiceBrowser(zc, SERVICE_TYPE, CameraListener())
# allow a few seconds, then zc.close() and read `found`

Zeroconf, ServiceBrowser and parsed_addresses are the documented API of the zeroconf package (pip install zeroconf); the prefix and buffer are yours. Prove the result before wiring it into production: run the listener beside avahi-browse -arp in a second terminal, and both must print the same field-eight value within seconds; ping on that address must reply once the modes match; the SDK session on it must open. On a link with several identical units the prefix check does the sorting, and if two cameras still collide on one host, the duplicate-name fix for two identical GigE cameras settles the address and name side.

Does the same fix work for GigE Vision cameras?

The failure mode is identical and the discovery channel differs: GigE Vision cameras answer subnet broadcast rather than mDNS, which is why a discovery tool still finds them on the wrong subnet while ping and arp-scan come up empty.

That broadcast discovery is what a setup or force-IP tool uses to find a camera on the wrong subnet and offer to rewrite its address — the same dialog from the timeout section, with a cousin underneath it. The durable answer repeats: enable the camera's DHCP client mode in its network settings, or give it the private second NIC from the architecture above. Both halves are documented step by step in why GenICam discovery uses subnet broadcast and forcing the IP assignment for a GigE camera on a different subnet. The playbook covers 3D sensors and area scan cameras alike — the network neither knows nor cares what the camera looks at.

When the network side is settled, the rest of the chain is a short walk: the camera finder filters by interface and resolution, the configurator pairs the camera with lens, cable and light, and the 3D topic page collects the integration fixes that start where this one ends. If a station design hangs on the network layout, describe the cell on the contact page and we will review the ports and subnets with you.