Why a UDP broadcast IP change is not guaranteed, and what works

You set the new address, the utility prints a confirmation, and ten minutes later the camera still answers on the old one. That loop wastes commissioning hours on GigE smart cameras, fixed code readers and vision controllers alike, and it usually traces back to one of three things: the transport, a firewall, or the subnet. This guide shows you how to tell them apart with tests that take minutes, then how to make the change stick through a direct TCP session and prove it with a fresh discovery and a ping. Work through the sections in order. By the end you will know which failure you had, the fix that matches it, and the four-step check that keeps it from returning.

Why does the camera keep its old IP address after you save the change?

The change did not reach the camera: your configuration tool sent it as a UDP broadcast, and a broadcast is fire-and-forget, so nothing in the transport confirms delivery and a firewall, a router or a busy link can drop it silently while the old address survives.

The symptoms are consistent. The dialog closes with a success message. Discovery still lists the old address after a refresh. Ping answers on the old address and stays silent on the new one. The command looked accepted because sending it succeeded; UDP gives your PC no way to notice a drop.

Rank the causes before you touch anything:

1. The tool sent the change as a UDP broadcast and something between PC and camera dropped it.
2. The camera sits on a different subnet, so the broadcast never had a path.
3. The change reached the camera but stayed in working memory, and the next reboot reverted it.
4. Another device already holds one of the addresses, so the replies you see come from the wrong unit.

Each cause has a two-minute test below, and the fix differs for each.

Which failure is it, and which test proves it?

Test in this order: a discovery refresh with the host firewall off proves the firewall, an AND of both addresses against the mask proves the subnet, a power-cycle ping proves the missing commit, and a one-by-one unplug proves a duplicate address.

Run the tests top to bottom; the first one that changes the behavior names your cause.

Why does UDP broadcast give no delivery guarantee?

UDP is a connectionless protocol: the sender transmits one datagram and considers the job done, with no handshake, no acknowledgement and no retransmission, so 'the tool sent the command' and 'the camera received it' are different events.

UDP hands the message to the network and forgets it; a dropped datagram is invisible to the sender. Broadcast makes it worse: the command goes to every host on the segment, and routers do not forward broadcasts — most are configured to drop even subnet-directed ones such as 192.168.3.255. The tool's success message means the send call returned, nothing more.

TCP is the opposite. A three-way handshake opens the session, every segment is acknowledged, and lost segments are retransmitted until the camera's stack confirms them. When a command returns over TCP, the camera has the bytes. The same broadcast mechanics explain related faults, such as why UDP broadcast discovery fails when a PC holds several IPv4 addresses.

Does a firewall drop the configuration broadcast?

It can, and on a default Windows install it often does: the firewall treats an unsolicited UDP broadcast and its reply as unsolicited traffic and discards it, while an established TCP session passes once you allow the port, so the same command succeeds over TCP and dies over broadcast.

On a stock Windows profile, inbound UDP that no connected session asked for gets dropped, and a discovery reply is exactly that. The result reads as 'the change did not take' when the change never completed the conversation. GigE Vision control traffic runs on UDP port 3956, so one inbound rule for UDP 3956 brings discovery and broadcast configuration back on a blocked host.

The test is fast: on an isolated bench switch, repeat the change once with the host firewall off. If it sticks, build the rule for the ports your camera utilities use and turn the firewall back on. Never commission with the firewall disabled. The pattern — ping works, discovery fails — is dissected in why a GigE Vision camera firewall lets ping through but kills discovery.

Does the camera sit on a different subnet than your PC?

A broadcast never crosses a router, so if the camera's subnet differs from your NIC's, no broadcast tool can reach it, and one AND operation per address settles the question.

The fix is to meet the camera on its own wire. Set the host NIC to a free address in the camera's subnet — 192.168.3.10 in the example, anything from 192.168.3.1 to 192.168.3.254 except the camera's .50 and the gateway — rediscover the unit, and make the change over the direct session in the next section. If the plant address is 10.31.40.61 with mask 255.255.255.0, move the NIC into 10.31.40.x afterwards and ping to confirm. The same arithmetic explains the 3D-camera case where ping fails until the controller's NIC joins the camera subnet, covered in fixing a 3D camera that is not pingable on a Linux controller.

This check applies to every Ethernet smart camera and fixed code reader you commission:

How do you set the address so the camera confirms it?

Open a direct host-to-host session with the camera — the maker's TCP command interface, reached with a telnet-style client on the camera's command port — send the address change on that session, and the camera acknowledges every byte before your prompt returns.

1. Put the host NIC on the camera's current subnet and ping its present address. No reply means the subnet or firewall test still has work to do; a session cannot open to a silent camera.
2. Open the connected session: the utility's direct or unicast connection mode, or a telnet-style client on the command port listed in the camera's command manual. Log in with the credentials your plant assigns.
3. Send the set-address command, then the save or commit command, both from the maker's command set. Order matters: an uncommitted change dies at the next reboot.
4. Close the session cleanly instead of power-cycling mid-transaction. An interrupted write is how half-applied settings happen.
5. Move the NIC to the new subnet and run the proof in the next section.

The channel that carries a confirmed production trigger carries configuration just as well; the pattern in triggering a smart camera over TCP with ASCII commands is the same transport: one socket, explicit replies, no silent drops. The walkthrough for changing a camera IP address when the update tool is stuck on the default covers the utility-side version of the same procedure.

How do you prove the new address took effect?

Re-run discovery from a host on the new subnet and ping the camera: discovery lists what the camera currently advertises, ping proves the stack answers at the new address, and both together close the doubt that a 'sent' message leaves behind.

1. Discovery run from the new subnet lists exactly one entry with the new address. GenICam discovery walks the subnet broadcast, so run it from a NIC that shares the camera's network; why ping alone is not enough for GenICam discovery explains what discovery does that ping cannot.
2. Ping the new address and count replies with zero loss.
3. Check the ARP table entry for the new address against the MAC label on the camera. A mismatch means a different device answered.
4. Ping the old address and expect a timeout. If both addresses answer, the old one belongs to something else.
5. Power-cycle the camera, let it boot, and ping again. The address must return on its own; that is the non-volatile commit proving itself.

Five checks take about five minutes for one camera. For ten cameras the sweep is most of an hour, and afterwards every address on the line is accounted for.

When is a broadcast change still the right choice?

On a bench with one switch, no firewall between PC and camera, and both addresses inside one /24, the broadcast utility is fine, provided you treat its 'saved' message as 'sent' and confirm each unit with a fresh discovery before moving on.

Bulk commissioning on one cell network is the natural case: a dozen code readers behind a single switch, addresses planned inside one /24, no router in the path. The utility re-addresses units quickly, and on a flat, quiet segment the datagrams arrive. The discipline does not change — ping and discovery after every unit — and the failure mode to respect is scale plus routing: once a router or a host firewall sits between you and the cameras, the arrival rate you cannot observe becomes the error rate you cannot explain.

When the cameras keep their own subnet permanently, a vision controller with several independent LAN ports holds one port on the camera network, so commissioning never touches the plant side:

What stops the same failure from coming back?

Standardize on the connected path: one inbound firewall rule for the camera utilities' ports, the host NIC template per line subnet, and the commit-power-cycle-ping-discovery check written into the commissioning sheet.

• Keep a one-page network plan per line: camera subnet, mask, planned address range, and two free addresses reserved for bench work.
• Deploy the firewall rules for camera traffic as policy, not as a technician's temporary exception; the port discipline in vision controller to PLC: TCP ports and firewall rules is the same habit.
• Write the four-step check into the sheet — commit, power-cycle, ping, discovery — and accept no signature without all four.
• Ping the planned address before connecting a new camera. A reply means the address is taken; pick another and note it.
• Label each camera with the last four digits of its MAC and its address. When a unit returns from the bench, the label is the truth.

For a camera whose address nobody remembers, the maker's factory-reset procedure returns it to its default address on the default subnet; the reset sits in the hardware manual, usually a button or a menu item. Re-address over a TCP session and run the power-cycle test before remounting. And when discovery itself is unreliable — filtered broadcast, odd switch behavior — connecting a GigE Vision camera without broadcast discovery lists the paths that still work.

To plan the hardware around this checklist, start from the camera finder or build the station in the system configurator. More connection troubleshooting sits on the systems topic page, and our team answers network-planning questions through the contact page.