GenICam discovery uses subnet broadcast: why ping is not enough

Your GenICam browser lists no cameras, the camera answers ping, and arp -a shows its address — and switching on the ignore-subnet option changes nothing. That combination points at one mechanism, not a dead camera or a bad cable. GigE Vision discovery travels as a UDP broadcast that never leaves its own subnet, while ping travels as routed unicast, so the two tests exercise different paths and can legitimately disagree. This page gives you the mask arithmetic that settles the addressing question in seconds, the five-step fix with a force IP and a persistent IP write, the packet capture that catches a broadcast leaving on the wrong interface, and the NIC alias that keeps two subnets alive on one wire when plant addressing cannot move.

What discovery puts on the wire

GigE Vision control traffic runs over UDP port 3956, the GigE Vision Control Protocol. When you refresh a GenICam browser, it sends a discovery command as a broadcast: either the limited broadcast address 255.255.255.255 or the directed broadcast of the NIC's subnet, 10.0.0.255 under a 255.255.255.0 mask. Every camera that hears the broadcast answers with a unicast reply carrying its IP address, MAC address and identity. Routers never forward the limited form and drop directed broadcasts by default, so discovery sees only cameras whose subnet matches the NIC it went out on. Every GigE Vision camera in the GigE area scan cameras category behaves identically here:

The AND is bitwise, and it settles the whole question: if the two network addresses differ, no number of successful pings makes discovery work.

Why ping and arp -a still succeed

Ping is unicast IP traffic. To reach a camera outside its own subnet, the host consults its routing table and hands the packet to a gateway, a static route or a second interface that knows the way; routers then forward the packet hop by hop. The camera answers, and the ICMP round trip completes across subnets. Discovery's broadcast gets no such service: it is delivered on-link only, and no router passes it along.

arp -a tells the same story. The ARP cache records any address pair learned from a past unicast exchange — your earlier ping, a force-IP attempt, another tool that talked to the camera. A populated entry proves the address and the link are alive; it says nothing about whether the camera ever heard a broadcast.

So the two results are consistent, not contradictory. Ping green with an empty browser indicts the broadcast path — the addressing or the interface — not the cable.

Four causes, checked in this order

The symptom is fixed, so work the causes in this order. The first two cover most bench cases, the third catches embedded and virtualized hosts, and the fourth the filtered networks.

1. The NIC and the camera sit in different subnets

A camera on a default or plant range such as 192.168.1.10 against a host NIC at 10.0.0.2 fails the test before any software runs:

Different network addresses: the broadcast cannot arrive, so discovery stays empty no matter what the ignore-subnet switch does. A camera that lost its DHCP lease falls back to link-local addressing, a range with rules of its own; the guide to opening a link-local camera by IP from Linux covers that state.

Fix: the five steps in the next section — move the camera into the NIC's subnet and store the address as a persistent IP.

2. The ignore-subnet option covers less than you expect

Some browsers ship an Ignore Subnet Discover switch that probes beyond the local subnet. Implementations differ, and on some default installations it does not probe every range, so the camera stays invisible with the switch on. Treat it as a diagnostic, never as a design.

Test: move the NIC into the camera's subnet and refresh with the switch off. A camera that appears at once proves the addressing was the only fault.

Fix: matching subnets plus a persistent IP. A production station must not depend on a switch whose coverage varies from install to install.

3. The broadcast leaves through the wrong interface

Hosts with several NICs, Wi-Fi adapters, virtual bridges from container or virtualization tools, and USB networking give the broadcast many ways out. A tool that follows the default route or takes the first interface in the list sends the discovery onto a wire the camera never sees.

Test: capture on the camera's own interface while refreshing — on Linux:

sudo tcpdump -ni eth0 udp port 3956

No outgoing discovery packet means the broadcast went elsewhere. Bring the other interfaces down, refresh, and the camera appears. The GenTL discovery guide for containers covers the container-bridge variant. A virtual machine on NAT shares neither the subnet nor the broadcast domain — the same mechanism behind a virtual-machine guest that cannot ping a device on its own subnet — so bridge the adapter instead.

Fix: select the interface in the tool where that choice exists, or commission with one interface up and the rest down.

4. Something filters the broadcast or the reply

A host firewall that blocks inbound UDP 3956, security software that drops unknown replies, or a switch port with aggressive broadcast limiting all produce the same signature: ping fine, discovery empty.

Test: in the capture above, look for the camera's unicast reply after each outgoing discovery. A reply that reaches the host while the browser stays silent indicts host software; no reply at all points back to the wire or the camera.

Fix: allow UDP 3956 in both directions on the camera NIC. The full firewall procedure lives in GigE Vision camera firewall: ping works, discovery fails.

Fix: five steps to a camera that always appears

Plan the bench first: one /24 per camera group. A 255.255.255.0 mask leaves 254 usable host addresses, 10.0.0.1 through 10.0.0.254, with 10.0.0.0 reserved for the network and 10.0.0.255 for the broadcast. Put the host NIC at 10.0.0.1 and start cameras at 10.0.0.10.

1. Read both sides: the NIC's address and mask, and the camera's current address — from its earlier configuration, its label, or the address that answers ping.
2. Set the host NIC temporarily into the camera's subnet: camera at 192.168.1.10 means NIC at 192.168.1.2 with mask 255.255.255.0.
3. Refresh the browser with the ignore-subnet switch off. The camera appears. In the camera's network configuration, write the bench address — 10.0.0.10, mask 255.255.255.0 — as a persistent IP, and take the camera out of DHCP-only operation.
4. Apply a force IP so the new address takes effect immediately, then return the NIC to 10.0.0.1.
5. Power-cycle the camera and refresh once more. Discovery now finds it on every boot, with no switch and no workaround; a final ping confirms the unicast path too.

The reboot in step 5 is the proof: it tests the stored configuration, not a temporary address.

Worked example: same-subnet bench, discovery still empty

The stubborn variant shares a subnet already: host NIC at 10.0.0.2, camera at 10.0.0.12, ping green, arp -a listing the camera, and the browser empty with the switch on or off. The arithmetic says discovery should work:

Same network, so the failure is in the broadcast's path. Run the capture on the camera's interface and refresh — the Linux command above — and read one of three outcomes:

• Broadcast out and reply back, browser silent: the host received the answer and its software dropped it. Cause 4.
• Broadcast out, no reply: the reply was filtered, or the broadcast actually left on another interface. Re-run the capture per interface.
• Nothing outgoing on the camera's interface: the browser broadcast elsewhere, typical where a virtual bridge or Wi-Fi adapter is up. Cause 3.

Decision: once the capture shows broadcast and reply on the camera's wire, discovery completes without the ignore-subnet switch — and the persistent write from the five steps makes it permanent.

Keep two subnets on one wire

Plant addressing sometimes cannot move: the NIC must stay at 10.0.0.x for the control network while the camera is configured for 192.168.1.x and has to keep it. Discovery can still work — give the same NIC a second address in the camera's subnet:

sudo ip addr add 192.168.1.2/24 dev eth0

On Windows, add the address under the adapter's IPv4 advanced settings and leave the gateway field empty. The NIC then holds 10.0.0.2/24 and 192.168.1.2/24, the browser broadcasts into both networks on that wire, and the camera treats 192.168.1.2 as on-link for its reply and its stream. Keep the alias gateway-free so unicast to the control network still follows the default route.

This is the layout multi-port vision controllers are built for:

The MV-VC3301H-128G66 provides 5+ LAN ports; the MV-VC5525-256G70-NN pairs 5+ LAN ports with PoE camera ports, so each camera group can own a NIC and its own subnet.

Commissioning checklist

Six habits keep the browser populated:

• Static addresses on the camera NIC — a bench with no DHCP server otherwise re-runs this hunt after every reboot.
• One subnet per NIC, with the mask written on the cable label — the AND check then takes seconds.
• A persistent IP in every camera, confirmed after a power cycle, not only at set-up.
• Unused NICs and virtual bridges down on commissioning day, so the broadcast has exactly one way out.
• UDP 3956 allowed in both directions on the camera NIC in the host firewall.
• Each camera's MAC recorded beside its IP and switch port — a replacement then needs a two-minute force IP and persistent write.

The wider bring-up sequence, from target discovery to first images, is in the embedded vision system project setup checklist.

When the cause is none of these

Three neighbouring faults look similar and have their own pages:

• Ping fails too: the link, cable or switch port is at fault — check link LEDs before anything here.
• Discovery lists the camera but no images arrive: the stream uses ports negotiated separately from discovery, so a firewall that passed the broadcast still drops the stream — GigE Vision firewall troubleshooting for missing images.
• No camera of any kind appears in any tool: the GenICam transport layer is missing on the host — Ping works, zero cameras: GigE transport layer not loaded.

For a first-time bring-up on a new host, start with GigE camera not detected: subnet and compliance checks first, which orders the checks that precede the fixes on this page.

Next step

Pick the camera in the camera finder or start the camera configurator with your NIC count in mind. If plant network policy fixes the addressing and the alias layout does not fit it, describe the topology through the contact page and we will propose the NIC and subnet plan. Every network bring-up page sits together on the systems topic page.