GigE camera IP address subnet mismatch: fix the connection

Link LEDs glow at both ends and the camera is powered, yet the software lists nothing — or lists the camera and refuses to open it. In most first-connection failures the camera and the card are innocent: the camera's IP address and the host NIC's address sit in different subnets, and a GigE camera only opens for a host that shares its subnet. This page gives you the rule, the subnet arithmetic that checks it in two minutes, the likely causes ranked by how often they turn out to be the culprit, and the three fixes: move the NIC, give the camera a persistent IP, or force IP once to get in. Work it in order and you will know within ten minutes whether the problem is the address — and if it is not, which part to suspect next.

Symptom: link on, camera missing or unreachable

Two flavors, and they point at different halves of the problem. Flavor one: the device list stays empty although the LEDs are lit. Flavor two: the camera appears but the connect fails, the entry is greyed out, or the tool offers a force-IP dialog. Flavor two is the subnet-mismatch signature. Listing rides on a broadcast, which is why GenICam discovery uses a subnet broadcast and ping alone proves nothing: a camera in a foreign subnet can still answer that broadcast. Everything afterwards — opening the control session, reading registers, streaming — is unicast traffic to the camera's address, and unicast needs a matching subnet.

Do the address check before anything else. It costs nothing, it explains most dead-looking cameras, and it splits an addressing problem from a hardware one in a single step. Every camera in the GigE area scan cameras range follows the same addressing rules, so the procedure below applies whatever the model.

The rule: one subnet, or it will not open

AND works octet by octet: 255 keeps a number, 0 discards it. With the usual 255.255.255.0 mask (a /24) the whole test collapses to one line — the first three numbers of the two addresses must be identical. With 255.255.0.0 (/16) only the first two must match. Link-local addresses live in 169.254.0.0/16 under that /16 mask: a camera or NIC that asks DHCP for an address and gets no answer helps itself to a random 169.254.x.x value. Typical factory behavior for a GigE camera is exactly that — ask first, fall back to link-local — so an unconfigured camera and an unconfigured NIC often find each other by accident.

Worked example: two minutes of arithmetic

A bench camera holds the persistent address 192.168.1.10 with mask 255.255.255.0. The host NIC has been on the office network, a docking station and a bench switch over its life, so it has held each address below at some point. The camera's network comes first:

Check the first line by hand: 192 keeps, 168 keeps, 1 keeps, and 10 AND 0 gives 0 — the camera sits in 192.168.1.0. A NIC at 192.168.1.3 shares that network, so the camera opens. The other three rows land elsewhere and cannot open it, however healthy the card is. The link-local row hides a subtlety: those addresses carry a 255.255.0.0 mask, so they compare two octets, not three. Had the camera also fallen back to link-local — say 169.254.183.22 — its network would be 169.254.0.0, the same as the NIC's, and the pair would connect. That is why a dead DHCP server can make a half-broken line look alive.

Decision: if the two AND results differ, this is an addressing problem. Fix the addresses and leave the driver and the card alone.

On the bench this arithmetic usually involves a model such as the MV-CU020-90GC, a 2.5 MP C-mount GigE camera.

Likely causes, most probable first

Run the list in order; the first two items account for most cases.

1. NIC in the wrong subnet. The NIC picked up an office or docking-station address — 192.168.2.31 in the table — while the camera holds a persistent bench address. Test: read the NIC's address from the operating system, ipconfig on Windows or ip addr on Linux, and run the two-line AND.
2. Camera on link-local, NIC elsewhere. No DHCP server answered the camera, so it sits at 169.254.x.x while the NIC is static on another subnet. Test: look for 169.254 in the device entry the tool shows.
3. Two adapters answering. Onboard port plus add-in card, or Wi-Fi still up: the reply leaves on the wrong interface and the session dies mid-open. Test: disable every adapter except the camera's and retry. The permanent setting is in GigE camera on multiple network interfaces: pick the right NIC.
4. Firewall on UDP 3956. Discovery and control ride on that port, so a strict host profile blocks both and the list stays empty. Test: on a bench machine, disable the firewall for one minute. If the camera appears, write a rule for the tool instead of leaving the firewall off.
5. Hardware. A dark link LED, a crushed cable, an RJ45 socket wrenched sideways on the card. From the software side this looks exactly like a subnet mismatch, and a torn socket has cost more than one afternoon of driver reinstalls. Test: LEDs at both ends, swap the cable, try the camera on a laptop before opening the PC.

Fix 1: move the NIC to the camera's subnet

The bench and single-camera fix: keep the camera untouched and make the host match it.

1. Read the camera's address and mask from the device list or the housing label — 192.168.1.10 / 255.255.255.0 in the worked example.
2. Set the NIC static in the same subnet on an address nothing else holds: 192.168.1.3, mask 255.255.255.0, gateway left empty.
3. Disable the other adapters for the test, Wi-Fi included, so replies cannot leave on the wrong interface.
4. Rediscover, open the camera and stream one image. A ping to 192.168.1.10 works only now that the subnets match, which is what makes it a usable confirmation at this point.

Keep this arrangement on a bench: static NIC in the camera's subnet, camera on DHCP with link-local fallback, so the same camera works when you move it to another PC. If the onboard port is the variable you no longer trust, a dedicated card removes it: the MV-GE2002P is a dual-port PoE NIC and the MV-GE1104 a 4-port GigE frame grabber, while 10GigE cameras get the same treatment from the MV-GT2104 quad-port copper 10GbE NIC.

Fix 2: give the camera a persistent IP

When the NIC must keep its address — a plant network at 10.0.7.5, say — move the camera instead. You need one working session first, through fix 1 or fix 3; after that the camera holds the address through power cycles.

1. Connect once with the NIC temporarily set into the camera's current subnet.
2. In the configuration tool, switch the camera from DHCP to a persistent IP: 10.0.7.60 with mask 255.255.255.0. Set a gateway only if the camera must someday reach a different subnet; on a dedicated camera subnet leave it empty.
3. Save, power-cycle the camera and rediscover: it should return on 10.0.7.60 with no warning flags.
4. Write the address on the housing and into the cell file.

Choosing the address: on a dedicated camera subnet, any unused address works. On a shared office network, stay off the addresses the DHCP server hands out — read its pool range in the router's LAN settings and pick above or below it. Where the camera must deliberately live on another subnet from the host, with routing between them, connecting a GigE camera on a different subnet covers the remote and local IP set-up.

Decision: every camera bolted into a line gets a persistent IP. DHCP with link-local fallback is for the bench.

Fix 3: force IP once, then make it permanent

Force IP is the designed way into a camera you cannot reach. The configuration tool sends the offered address straight to the camera's MAC address as a broadcast; the camera adopts it immediately and holds it until the next power cycle — temporary by design, which is what makes it safe.

1. Let discovery run even though the entry reports a foreign address: the listing carries the MAC the command needs. If nothing lists at all, jump to the hardware checks.
2. Run the tool's force-IP function with an unused address in the NIC's subnet: NIC at 10.0.7.5, camera offered 10.0.7.61.
3. The camera answers on 10.0.7.61 straight away; open it.
4. Set the persistent IP now, while you are connected, because force IP dies with the next power cycle.
5. Power-cycle once and confirm the camera comes back on 10.0.7.60.

Force IP crosses subnets but not routers: camera and NIC must share one broadcast domain, which a direct cable or an unmanaged switch always provides.

Prevention: an addressing plan that survives a reboot

• Persistent IP on every camera bolted into a line, DHCP off. The bench camera can stay on DHCP with link-local fallback.
• One subnet per NIC, one unused address per device, every mask 255.255.255.0 — the exact two-NIC address plan is in the question about planning addresses above. The bandwidth side of that layout is in two GigE cameras on one host: NIC ports and bandwidth budget.
• Addresses on the housing labels and in the cell file, so the next commissioning is reading rather than debugging.
• The camera on its own cable or switch, never hung off the office VLAN where some DHCP server can answer it.
• Configuration tools and firmware from the camera manufacturer's own download pages only. A tool that mismatches the camera's firmware is its own failure mode, covered in camera firmware version mismatch: fix detection failures safely.

Checks before you blame the card

Sixty seconds, in this order:

• Link LEDs lit at both ends — a dark LED ends the software discussion immediately.
• NIC address read from the OS with ipconfig or ip addr, not from memory.
• Both AND results equal — the two-minute test from the worked example.
• One adapter enabled toward the camera, Wi-Fi off during the test.
• Firewall allows UDP 3956 to the configuration tool.
• Camera tried on a laptop: a laptop that connects convicts the cell PC's set-up; nothing connecting anywhere convicts cable, port or camera.

The wider bring-up sweep — driver, packet size, compliance settings — is in GigE camera not detected: subnet and compliance checks first. Once the camera opens and streams, addressing is finished: torn lines and dropped frames belong to the stream, and GigE Vision packet loss with horizontal lines plus incomplete frames from a driver and NIC MTU mismatch pick up from there.

When the usual answer is wrong

• Subnets match, the tool lists the camera, and your application still cannot open it: another client holds the session, because a GigE camera serves one primary controller at a time. Close the other client — or the second application using the same camera — and retry yours; if the tool and the application must both reach the camera, use the tool as a passive observer where it supports that mode.
• The second camera on a shared NIC drops when the first starts streaming: give each camera its own NIC and subnet, then re-read the bandwidth numbers for that pair.
• The camera hangs off a robot controller or PLC port rather than a PC. The one-subnet rule does not change. On the controller side, the notes on connecting a GigE Vision camera to a robot controller apply the same arithmetic at the controller's port. The walkthrough on resolving a PLC-to-PC subnet mismatch shows the identical fix on a control network.

Decision, case by case

• Camera at 192.168.1.10, NIC anywhere else, one camera on a bench: set the NIC static at 192.168.1.3 with mask 255.255.255.0. Five minutes, the camera untouched, done.
• NIC must keep its plant address: force IP to 10.0.7.61 once, set the persistent 10.0.7.60, power-cycle, done.
• Addresses match and the LEDs are dark on every host: cable first, then port, then the card. Hardware comes last because it is the costliest thing to replace on a guess.

If you are provisioning rather than repairing, the camera finder filters GigE models by resolution and mount, and the camera configurator pairs the camera with interface and accessories in one pass; the systems topic page collects the rest of the bring-up guides. For a case that resists all of the above, contact the team with the two addresses and both masks — the AND result usually settles it in the first reply.