Camera IP conflict: ping works but the web page is wrong

You ping the camera and the reply comes back in a millisecond. Then the browser opens a stranger's web server. Nothing about that combination is exotic: a ping proves only that some interface answers at the address you typed, never that the device is the one you meant. This page is for anyone commissioning machine-vision cameras, vision sensors or other addressed devices on a shared plant network. You will prove which device holds the address, find a camera sitting on its factory default or link-local address, give it an address that cannot collide, and leave behind a register that keeps the fault from coming back.

Why does ping work but the browser show the wrong page?

Because ping and the browser both talk to whichever device actually owns the address: ping asks its network stack for any reply, while the browser asks its web server for a page, so when a Windows server owns that address, both answers come from the server.

An IIS welcome page is served by Internet Information Services, the web server that ships with Windows Server. No camera serves that page, so the address you typed belongs to a server, and your camera is somewhere else entirely. The usual story is that the camera's address exists only on paper, in a handover note or a spreadsheet, and nobody checked it against reality. The reply you measured is real, honest and from the wrong machine.

Trace it from the bottom of the stack. Ping is answered by the interface at that address, and identity lives in the MAC address one layer below. The page is served by applications on top. The two tools sit at different layers of the same device, so the symptom never splits in two: if the page is a server's, the ping reply was the server's as well.

Could a bad cable or switch cause it?

No: a wiring or switching fault leaves the address silent and the ping times out, so a reply already proves a working electrical path from your PC to the interface that answered.

Link LEDs, connector seating and latches are still worth a glance, because a marginal link produces intermittent dropouts later, but it cannot produce the wrong page today. A cable decides whether anyone answers, never who answers. If you do re-terminate a run on a moving axis, choose cable rated for the duty: camera data and I/O cables come in fixed-length and drag-chain grades, and the difference shows up after a few weeks of flexing.

On an axis that flexes all day, a drag-chain-rated GigE cable with screw locks keeps the link stable:

How do you prove which device answered the ping?

Unplug the camera and ping the address again: if the replies keep arriving, the answering device is not the camera, because the address belongs to something else that is still powered.

That unplug test takes ten seconds and settles the question without any software. If the replies stop, the camera really was the answerer and the fault is configuration rather than conflict. If they continue, a conflict is proven, and the owner of the address is still running.

Your PC also keeps the mapping. The ARP table lists the MAC address behind every address it has spoken to recently, and arp -a prints it on Windows, Linux and macOS. The first three octets of a MAC, called the OUI, name the maker of the interface, and public OUI lookup tools decode that string in seconds. Compare the result with the label on the camera housing: a match means you were talking to the camera after all, and anything else names the true owner.

A managed switch shortens the walk: its tables record which physical port learned the camera's MAC, so you can head straight to the right cabinet.

This ambiguity is not a camera specialty. On the PLC side, the same pattern appears as Modbus TCP sessions that fail while a radio link keeps answering every ping, and when TIA Portal cannot reach a PLC although every ping replies, the culprit usually sits in the PC's interface selection rather than the wire. The diagnosis starts at the same layer every time: prove who is really behind the address.

Is the camera still on its factory default IP address?

Most of the time, yes: the most common cause of this symptom is a camera that never received its commissioning address, or that fell back to a default after a reset, so it is answering somewhere you have not looked.

Factory defaults sit in small private ranges, with 192.168.0.x and 192.168.1.x the usual neighborhoods, and the default is printed on the label or in the manual. A camera also returns to that state after a factory reset, which restores the network settings along with everything else. The quietest path: someone configured it with a tool that forced the address for the session and never wrote it as persistent, so the first power cycle rolled it back.

When no DHCP server answers, a GigE camera does not sit silent either: it picks a link-local address in 169.254.0.0/16, and vendor documentation describes the working range as 169.254.1.0 through 169.254.254.255. Your PC does exactly the same, which is why both ends often stay reachable for discovery even when neither holds a proper address.

Every one of these states answers a ping somewhere. None of them answers at the address on the commissioning sheet. A reply here and an expectation there is the fingerprint of a default or fallback address.

How do you find a camera that discovery does not list?

Ask the network instead of the address book: a GigE Vision discovery broadcast on UDP port 3956 returns every camera on the broadcast domain with its MAC address, current IP and device name, even when the IP is not the one you expected.

Run the camera's configuration tool, or any GenICam-based discovery, and read the list instead of assuming. The camera appears beside its true address and its MAC, and the hunt is over. Addressed devices across the shop behave this way, from an area scan camera on a machine to a vision sensor on its own drop cable.

If the list comes back empty, the adapter's subnet is the usual cause: discovery uses a subnet broadcast, which is why ping is not enough, and why GigE Vision discovery rides on a subnet broadcast explains the rule. Put the adapter temporarily on the camera's side of the fence, with a link-local 169.254.x.x address that matches a camera in the same state, and run discovery again. An empty list alongside working pings has two more usual suspects: a GigE transport layer that never loaded, and a firewall that passes ping but blocks discovery.

Vision sensors on Fast Ethernet hold an address the same way, and their configuration tools discover them the same way:

When the device connects but frames never arrive, the addressing layer is behind you and the failure has moved up a floor: timeouts where ping works and no pixel data arrives cover that next step.

What IP address should you assign so it never collides?

Give the camera a unique static address inside the camera network's subnet and outside the DHCP pool: a 255.255.255.0 netmask leaves 254 usable host addresses, and the camera needs one that no lease and no other device can ever claim.

The worked example uses illustrative addresses; substitute your own when you run the arithmetic.

Check the candidate against three exclusions and it holds: .1 belongs to the gateway, .203 belongs to the PC, and .100 through .200 belong to the DHCP pool, which leaves .50 permanently clear. Two habits make the address stick. Write it as the persistent setting, never a session force, and record it the same minute. Where the camera hangs off one PC on an isolated link, keep camera and adapter in the same subnet, and give the adapter itself an address in that subnet.

Sites that must keep DHCP can pin a device with a reservation; note that some operations are happier still with a static address, and why a firmware update wants the DHCP clutter out of the way covers that case. The full walk-through of writing a new address, and of cleaning up tools that stayed stuck on the old default, is in changing a camera IP address when tools are stuck on the default.

A GigE area scan camera carries its persistent network settings internally, so the address travels with the camera between machines:

How do you stop the same IP conflict happening again?

Write it down at the cabinet: a register that lists each device, its MAC address and its assigned IP turns the next visit into a lookup instead of a guess.

Keep the register where the next person will find it, as a spreadsheet on the controls share, a printed sheet inside the cabinet door, or both. Record the device, its MAC address, its assigned IP, the subnet it lives in and the date. Label the camera or its cable with the final address; a strip of tape reading 192.168.21.50 stops the next commissioning visit from starting with a ping and a prayer.

When a DHCP server manages the plant side, prefer reservations over raw leases for every addressed device, so the register documents intent rather than a changing state. Re-run the discovery list after every change and set it against the register: a device that appears twice, or appears where the register says nothing, is tomorrow's fault caught today.

What do you check before you close the job?

Power the camera off and on, re-run discovery, and accept the job only when the camera appears exactly once, at the address you recorded, with no other device claiming the same number.

• Discovery lists the camera once, at the recorded address, with the MAC that matches the housing label.
• The browser at the new address shows the camera's own page, not a server's page and not another device's.
• The address survived a full power cycle, which proves it was written as the persistent setting rather than forced for the session.
• The address sits inside the planned subnet and outside the DHCP pool, and the register now says so.
• Connectors are seated and latched at both ends, with solid link LEDs on camera and adapter.

If you are standing up a new station instead of rescuing this one, pick the camera in the camera finder, let the camera configurator settle sensor, lens and light choices, and start the IP register on day one; the cheapest time to avoid this fault is before the first address is assigned. The systems topic page gathers the rest of the network-layer fixes, and free expert support comes with every order if you want a second pair of eyes on the plan.