August 11, 2026 · How-To

EtherNet/IP ListIdentity: How Device Discovery Works (UDP 44818)

Walk onto a site with an Allen-Bradley cabinet and you usually do not know the IP of every PLC, drive, and I/O block inside. You could guess subnet ranges and try them one by one. Or you could send a single packet that asks every EtherNet/IP device on the network to identify itself. That packet is ListIdentity, and it is how CIP device discovery has worked for two decades.

This guide explains what ListIdentity sends, what comes back, and why it is a UDP broadcast rather than a TCP connection. For the wider protocol context, see the CIP protocol guide and our port 44818 reference.

The Mechanism in One Paragraph

A client sends an EtherNet/IP encapsulation command ListIdentity (0x0063) as a UDP broadcast to port 44818 on the local subnet. Every CIP device that hears the broadcast replies — each with its own unicast UDP response containing an Identity object payload. The client collects all the replies and now has a list of every device: vendor, product name, firmware revision, serial number, and IP. No prior address knowledge required.

What the Identity Reply Contains

Each device's reply carries the attributes of CIP Identity object (class 0x01):

• Vendor ID — the ODVA-assigned numeric vendor code (e.g. Rockwell Automation = 1).
• Device type — generic PLC, drive, communication adapter, etc.
• Product code — the vendor's product number (e.g. 1756-L83E).
• Revision — major.minor firmware revision.
• Status — device-owned / owned state and fault flags.
• Serial number — 32-bit device serial.
• Product name — human-readable string ("1756-L83E LOGIX5563").
• IP address / socket — where to reach it for a TCP session.

The Discovery Workflow

1. Send ListIdentity as a UDP broadcast on port 44818 (to the subnet broadcast address, e.g. 192.168.1.255).
2. Collect unicast replies for a short window (typically a few hundred ms).
3. Render each reply's Identity fields in a device list.
4. Pick a device, open a TCP connection to its IP:44818, and RegisterSession to start reading tags. See reading tags without RSLinx.

Limits to Know

Broadcasts do not cross routers. ListIdentity finds devices on the local subnet (or VLAN) only. For multi-subnet sites you either enable IP-directed broadcast (rarely allowed), run discovery from a host on each subnet, or fall back to a configured device list. Managed switches that block UDP broadcasts also stop discovery. And ListIdentity tells you a device exists — it does not tell you what tags it exposes; that requires a connection and a tag-database query.

Doing It on macOS

MacTools EtherNet/IP Explorer sends the ListIdentity broadcast and renders every responding device with full Identity attributes. You browse the discovered list, click a PLC, and connect — no need to know or type an IP address. From there it is straight into tag browsing and reads. Native macOS, no RSLinx.

Frequently Asked Questions

What is EtherNet/IP ListIdentity?

ListIdentity is an EtherNet/IP encapsulation command (0x0063) sent as a UDP broadcast to port 44818. Every CIP device on the subnet that receives it replies with an Identity response containing its vendor ID, device type, product code, revision, serial number, and IP address. It is the standard way to discover all EtherNet/IP devices on a local network without knowing addresses in advance.

Why does EtherNet/IP discovery use UDP port 44818 and not TCP?

Discovery is a one-shot broadcast that must reach every device without setting up a connection. UDP supports broadcasts; TCP does not. A single UDP packet to the subnet broadcast address reaches all devices, each of which replies with its own unicast UDP response. TCP 44818 is reserved for the subsequent connection-based session and tag operations.

Does ListIdentity work across routers or subnets?

By default, no — UDP broadcasts do not cross routed subnet boundaries. Discovery works within the local subnet (or VLAN) only. To enumerate devices across subnets you must either configure IP-directed broadcast, use a discovery agent on each subnet, or query a directory service like a FactoryTalk Directory rather than relying on broadcast ListIdentity.

How do I discover EtherNet/IP devices on macOS?

Use a tool that issues the ListIdentity broadcast. MacTools EtherNet/IP Explorer sends the UDP 44818 broadcast on macOS and renders every responding device with its product name, vendor, firmware revision, serial number, and IP address, so you can pick one and connect without typing an IP.

Further Reading

• EtherNet/IP and CIP Protocol Explained
• EtherNet/IP Port 44818 Explained
• Read Allen-Bradley Tags Without RSLinx
• CIP Explicit vs Implicit Messaging