CIP Connection Manager Object Explained (Class 0x06)

Behind every Forward_Open is one object. Behind every Forward_Close, every Unconnected_Send, every “connection timeout,” every “out of connections” error — one object. The Connection Manager Object (Class 0x06) is the CIP object that allocates and manages all the connection resources in a device. If Forward_Open is the service, the Connection Manager Object is what answers the door.

This article explains the Connection Manager Object in depth — its attributes, its counter diagnostics, its object-specific services (Forward_Open, Forward_Close, Unconnected_Send, Large_Forward_Open, Get_Connection_Owner, and the diagnostic services), and how it sits at the heart of every CIP I/O connection. It builds on our CIP Forward_Open Service Explained article (which focused on the service); this one focuses on the object that implements it.

What the Connection Manager Object is in one paragraph

The Connection Manager Object (Class Code 0x06) is the CIP object that allocates and manages internal resources associated with both I/O Messaging Connections and Explicit Messaging Connections. Per Volume 1 Section 3-5, the Connection Manager allocates Connection Object instances (Class 0x05) when Forward_Open succeeds, releases them when Forward_Close succeeds or when a connection times out, and tracks counters for connection success/failure history. Every CIP device that supports connections — meaning anything that does I/O — implements exactly one instance of the Connection Manager Object at instance 1. It is the endpoint for every Forward_Open, Forward_Close, Unconnected_Send, Large_Forward_Open, Get_Connection_Owner, and connection diagnostic service.

Where the Connection Manager Object fits

The CIP specification splits connection-related responsibilities across two object classes:

Object	Class	Role
Connection Manager Object	0x06	Allocates connections, processes Forward_Open/Close, tracks diagnostic counters
Connection Object	0x05	Represents one specific established connection (Class 1 cyclic, Class 3 explicit, etc.)

Think of it this way: the Connection Manager Object is the factory and supervisor. The Connection Object instances are the individual connections the factory has produced. When Forward_Open succeeds, the Connection Manager creates a new Connection Object instance and returns its Connection IDs to the originator. When Forward_Close arrives, the Connection Manager deletes the corresponding Connection Object instance.

A device that has 16 active I/O connections has:

• 1 Connection Manager Object instance (instance 1)
• 16 Connection Object instances (one per active connection)

Both classes are part of Chapter 3 (Communication Object Classes) of Volume 1, but they serve very different roles.

Class attributes

Per Volume 1 Table 3-5.1, the Connection Manager Class has only optional class attributes (1-7) described in Chapter 4. Most devices implement only the Revision attribute (Class Attribute 1) — currently value 1.

The class supports two services per Volume 1 Table 3-5.2:

Service	Code	Need	Purpose
Get_Attributes_All	0x01	Optional	Read all class attributes
Get_Attribute_Single	0x0E	Conditional	Read individual class attribute

For most field troubleshooting, class attributes don’t matter — engineers go straight to instance 1 for the diagnostic counters.

Instance attributes — the diagnostic counters

This is where the operational gold lives. Per Volume 1 Table 3-5.4:

Attr ID	Need	Access	NV	Name	Type	What it counts
1	Optional	Set	V	Open Requests	UINT	Forward_Open requests received
2	Optional	Set	V	Open Format Rejects	UINT	Forward_Open rejected: bad format
3	Optional	Set	V	Open Resource Rejects	UINT	Forward_Open rejected: out of resources
4	Optional	Set	V	Open Other Rejects	UINT	Forward_Open rejected: other reasons
5	Optional	Set	V	Close Requests	UINT	Forward_Close requests received
6	Optional	Set	V	Close Format Rejects	UINT	Forward_Close rejected: bad format
7	Optional	Set	V	Close Other Rejects	UINT	Forward_Close rejected: other reasons
8	Optional	Set	V	Connection Timeouts	UINT	Total connections timed out
9	Optional	Get	V	Connection Entry List	STRUCT	List of all connection instances
10	Optional	Get	V	CPU Utilization	UINT	Connection management CPU usage
11	Optional	Get	V	MaxBuffSize	UDINT	Max buffer available
12	Optional	Get	V	BufSize Remaining	UDINT	Remaining buffer

The “Set” access for the counter attributes (1-8) and the “V” (volatile) flag are intentional — these are running counters that can be reset to 0 by writing them, but they don’t survive a power cycle.

Why these counters matter

Each counter answers a specific operational question:

Attribute 1 (Open Requests): Has anything tried to open a connection on this device? Reading a non-zero value means at least one originator has reached this device. Reading zero means no Forward_Open has ever reached it (or counters were reset).

Attribute 2 (Open Format Rejects): Are originators sending malformed Forward_Open requests? Incrementing values point to custom-written CIP client code with bugs, mismatched EDS configuration, or version incompatibility.

Attribute 3 (Open Resource Rejects): Is the device running out of connection resources? Returns of Extended Status 0x0113 (Out of connections) increment this counter. If you see this value rising, the device is at capacity and you need to close unused connections or get a larger device.

Attribute 4 (Open Other Rejects): Catch-all for everything else — electronic keying failures (Extended Status 0x0114-0x0116), invalid assembly paths (0x0117), RPI not supported (0x0111), ownership conflicts (0x0106). Most Forward_Open rejections fall here.

Attribute 5 (Close Requests): How often have connections been closed gracefully (via Forward_Close vs timeout)? High values relative to Connection Timeouts (Attribute 8) suggest the system shuts down connections cleanly. Low values relative to timeouts suggest unreliable network or improper shutdown sequencing.

Attributes 6-7 (Close Rejects): Forward_Close failures. Rare in practice — most Forward_Close requests succeed since they only require valid Connection Serial Number + Vendor ID + Originator Serial Number to match an existing connection.

Attribute 8 (Connection Timeouts): Connections that died via timeout rather than Forward_Close. Each timeout means RPI × Connection Timeout Multiplier elapsed without a packet. Persistent timeouts indicate physical network problems, switch issues, or CPU overload on the producer or consumer side.

Practical use — the connection health snapshot

Reading attributes 1-8 with Get_Attributes_All gives you the device’s complete connection-management history in one transaction. A healthy production device after a week of uptime might show:

Open Requests:           4,328  (lots of connections opened — normal)
Open Format Rejects:        0
Open Resource Rejects:      0
Open Other Rejects:        12  (occasional reconfiguration during commissioning)
Close Requests:          4,316
Close Format Rejects:       0
Close Other Rejects:        0
Connection Timeouts:        0  (no unexpected network drops!)

A device with 4,328 opens, 4,316 closes, and 0 timeouts has been running cleanly. Compare to a problem device:

Open Requests:           1,205
Open Format Rejects:        0
Open Resource Rejects:    143  (often out of connections!)
Open Other Rejects:        58
Close Requests:           892
Close Format Rejects:       0
Close Other Rejects:        0
Connection Timeouts:      218  (lots of timeouts!)

This second device has serious problems: 143 resource rejections (it’s at capacity), 218 timeouts (network instability). The difference between Open Requests and Close Requests (1,205 – 892 = 313) is close to the timeout count (218), suggesting most “missing” closes happened via timeout, not Forward_Close.

These counters are the single most useful diagnostic the Connection Manager Object exposes.

Attribute 9 — Connection Entry List

A STRUCT that lists which Connection Object instances currently exist. Per Volume 1 Section 3-5.3:

Field	Type	Purpose
NumConnEntries	UINT	Number of bit positions in the array
ConnOpenBits	ARRAY of BOOL	One bit per possible Connection Instance

The bit array is indexed so that bit position 0 represents Connection Instance 1, bit position 1 represents Connection Instance 2, and so on. A bit value of 0 means the instance doesn’t exist (or was destroyed). A bit value of 1 means the instance exists.

This attribute lets engineering tools enumerate all active connections without trying every possible instance number. Reading Attribute 9 gives you a complete bitmap of which Connection Instances are alive, then you can use Get_Connection_Data (Service 0x56) to fetch details about each one.

For devices that support hundreds of connections, this attribute is the fastest way to find which slots are in use.

Common services on the Connection Manager Object

Per Volume 1 Table 3-5.5:

Service	Code	Need	Purpose
Get_Attributes_All	0x01	Optional	Read all counters in one call
Get_Attribute_Single	0x0E	Conditional	Read individual counter or attribute
Set_Attribute_Single	0x10	Optional	Reset counters by writing 0

These work like any other CIP object’s common services. For broader service code coverage, see our CIP Service Codes Complete Reference.

Object-specific services

This is where the Connection Manager Object becomes uniquely important. Per Volume 1 Table 3-5.7, the Connection Manager defines these object-specific services:

Service	Code	Need	Purpose
Forward_Close	0x4E	Conditional	Close an established connection
Unconnected_Send	0x52	Conditional	Send an unconnected message (UCMM routing)
Forward_Open	0x54	Conditional	Open a standard CIP connection (max 511 bytes)
Get_Connection_Data	0x56	Optional	Diagnostic: get specific Connection Instance info
Search_Connection_Data	0x57	Optional	Diagnostic: find a connection by parameters
(0x59 — obsolete)	0x59	—	Obsolete
Get_Connection_Owner	0x5A	Conditional	Determine owner of redundant connection
Large_Forward_Open	0x5B	Optional	Open large CIP connection (max 65535 bytes)

These services are what the Connection Manager Object uniquely provides. They cannot be sent to any other class — they are object-specific. Every Forward_Open in CIP is sent to Class 0x06, Instance 1.

Forward_Open (0x54)

The primary service. Engineers see Forward_Open thousands of times in a Wireshark capture during commissioning. It establishes a CIP connection by:

1. Receiving a Forward_Open request with all the connection parameters (RPI, transport class, network connection parameters, connection path, electronic keying)
2. Validating each parameter against device capabilities
3. If valid, allocating a new Connection Object instance (Class 0x05) and returning its Connection IDs
4. If invalid, returning General Status 0x01 with an Extended Status code identifying what failed

The complete request structure, parameter-by-parameter walkthrough, and all 25+ Extended Status failure codes are documented in our dedicated CIP Forward_Open Service Explained article. The high-level rule:

• Forward_Open data size limit: 511 bytes per direction
• If your data needs more than 511 bytes, use Large_Forward_Open (0x5B) instead

Network Connection Parameters

The Forward_Open request includes a 16-bit Network Connection Parameters field per Volume 1 Table 3-5.8:

Bits	Field	Values
15	Redundant Owner	0 = exclusive owner, 1 = redundant owner allowed
13-14	Connection Type	00 = Null, 01 = Multicast, 10 = Point-to-Point, 11 = Reserved
11-12	Reserved	Must be 0
10	Priority	00 = Low, 01 = High, 10 = Scheduled, 11 = Urgent (uses two bits, see note)
9	Fixed/Variable	0 = Fixed size, 1 = Variable size
0-8	Connection Size	Data size in bytes (0-511)

Most field devices use exclusive-owner (bit 15 = 0), Point-to-Point (bits 13-14 = 10), Low priority, Fixed size.

Forward_Close (0x4E)

The graceful shutdown. Closes a connection identified by the originator’s identifying triple:

• Connection Serial Number (UINT)
• Originator Vendor ID (UINT)
• Originator Serial Number (UDINT)

When this triple matches an existing Connection Object instance, the Connection Manager:

1. Stops cyclic data exchange
2. Releases all resources allocated to that connection
3. Deletes the Connection Object instance
4. Returns success

Forward_Close vs timeout: explicitly closing is faster than waiting for the timeout to fire. A device whose connection times out via RPI × Multiplier exhaustion holds the resources until that time elapses. Forward_Close releases them immediately.

Unconnected_Send (0x52)

The service used by originators and intermediate routers to send a CIP message across multiple network hops. The request wraps a target CIP request (the actual operation you want done) with routing path information.

The Connection Manager at each hop:

1. Receives the Unconnected_Send
2. Strips its own port from the route path
3. Forwards the remaining message to the next hop
4. (At the final destination) Delivers the embedded CIP request to the target object
5. Carries the response back along the reverse path

This is how a ControlLogix PLC on EtherNet/IP reads a parameter from a DeviceNet drive through a 1756-DNB scanner — Unconnected_Send carries the routing breadcrumbs through each network boundary.

Forward_Open, Large_Forward_Open, and Forward_Close themselves are not bridgeable through Unconnected_Send — they can only be sent via UCMM or local explicit messaging on the target’s own subnet. This is a deliberate restriction in the spec.

Large_Forward_Open (0x5B)

Identical to Forward_Open in semantics but with extended Network Connection Parameters that support larger data sizes. The Network Connection Parameters field becomes 32 bits per Volume 1 Table 3-5.9, with the Connection Size field expanding to 16 bits — supporting up to 65,535 bytes per direction.

When to use Large_Forward_Open instead of Forward_Open:

• Connection size > 511 bytes
• Modern PLCs exchanging large structured tags via Class 1 cyclic I/O

When to use Forward_Open:

• Connection size ≤ 511 bytes (the majority of field devices)
• DeviceNet, ControlNet, or legacy CIP networks that don’t support Large_Forward_Open

Most engineering tools select between the two automatically based on the configured connection size.

Get_Connection_Owner (0x5A)

Used in redundant-owner scenarios. When multiple Logix controllers are configured for redundancy, multiple originators may compete for the same target device. Get_Connection_Owner asks the target: “Who currently owns this connection?”

The response identifies the current owner (Vendor ID, Connection Serial Number, Originator Serial Number), letting a backup controller determine whether the primary is still active.

For most installations this service is irrelevant — single-owner connections dominate. It matters in safety, redundant, or high-availability designs where Connection Manager Object diagnostics support failover decisions.

Get_Connection_Data and Search_Connection_Data

Diagnostic services for inspecting individual Connection Object instances:

• Get_Connection_Data (0x56): Given a Connection Instance number, return its detailed state — RPI, transport class, partner identification, recent timing statistics.
• Search_Connection_Data (0x57): Given a set of search parameters (Vendor ID, Connection Serial Number, etc.), return matching Connection Instances.

These services are rarely used by ordinary engineering tools but appear in advanced network analysis utilities and Connection Manager auditing software.

How Forward_Open flows through the Connection Manager

The complete path of a Forward_Open inside a target device:

1. Encapsulation layer receives the EtherNet/IP packet on TCP port 44818
2. Encapsulation unwraps the SendRRData command (0x006F)
3. CIP layer sees service code 0x54 with path to Class 0x06, Instance 1
4. Connection Manager Object Instance 1 receives the request
5. The Connection Manager:
   • Increments Attribute 1 (Open Requests)
   • Parses Network Connection Parameters, Connection Path, electronic keying, RPI, Timeout Multiplier
   • Validates each parameter against device capabilities
   • If electronic keying fails → return General Status 0x01, Extended Status 0x0114/0x0115/0x0116, increment Attribute 4 (Open Other Rejects)
   • If RPI out of range → return Extended Status 0x0111, increment Attribute 4
   • If at capacity → return Extended Status 0x0113, increment Attribute 3 (Open Resource Rejects)
   • If format malformed → return Extended Status (various), increment Attribute 2 (Open Format Rejects)
   • If all valid → allocate a new Connection Object instance (Class 0x05), return its Connection IDs
6. Reply travels back through SendRRData → encapsulation → TCP

Reading Attributes 1-8 after a problem session tells you the rough story of what went wrong — which categories of failures occurred.

The bridging restriction

Per Volume 1 Section 3-5.5.1: “The Forward_Open, Large_Forward_Open and Forward_Close services shall be sent using the UCMM or an unbridged (local) explicit messaging connection only. They shall not be sent over a bridged explicit messaging connection.”

This means: you cannot wrap a Forward_Open inside an Unconnected_Send and route it through multiple network hops. The Forward_Open must arrive at the target via its own local subnet or via UCMM. Engineering tools and PLCs handle this restriction automatically.

The reason: each hop along a bridged connection needs to receive and process Forward_Open to set up its own portion of the connection — wrapping the entire Forward_Open inside Unconnected_Send hides it from intermediate routers.

Reading the Connection Manager in Wireshark

Useful filters when troubleshooting connections:

cip                                       # All CIP traffic
cip.class == 0x06                         # All Connection Manager Object access
cip.service == 0x54                       # Forward_Open requests
cip.service == 0xD4                       # Forward_Open replies (0x54 with bit 7 set)
cip.service == 0x4E                       # Forward_Close requests
cip.service == 0x52                       # Unconnected_Send (routed messaging)
cip.service == 0x5B                       # Large_Forward_Open
cip.service == 0xDB                       # Large_Forward_Open replies
cip.service == 0x5A                       # Get_Connection_Owner
cip.cm.ext.code != 0                      # Frames with non-zero Connection Manager Extended Status

A useful diagnostic pattern: filter on cip.service == 0x54 to find every connection-open attempt, then for each one, look at the matching reply (cip.service == 0xD4). Failed Forward_Opens have General Status 0x01 and an Extended Status that identifies what went wrong — and the corresponding counter in the Connection Manager (Attribute 2, 3, or 4) tells you the failure category.

For broader Wireshark workflows, see our Wireshark for EtherNet/IP guide.

Common Connection Manager errors

Error scenario	Status returned	Counter incremented
Forward_Open with wrong assembly path	0x01 + Extended 0x0117	Attribute 4 (Open Other Rejects)
Forward_Open with bad electronic keying	0x01 + Extended 0x0114-0x0116	Attribute 4
Forward_Open with RPI too fast	0x01 + Extended 0x0111	Attribute 4
Forward_Open at device capacity	0x01 + Extended 0x0113	Attribute 3 (Open Resource Rejects)
Forward_Open with bad parameters	0x01 + (various)	Attribute 2 (Open Format Rejects)
Forward_Close with wrong connection ID	0x01 + Extended 0x0107	Attribute 6 (Close Format Rejects) or 7
Connection idle longer than RPI × Multiplier	(silent timeout)	Attribute 8 (Connection Timeouts)
Unconnected_Send with unreachable destination	0x01 + Extended 0x0204/0x0205	—

For complete error code coverage, see our CIP General Status Codes Reference — especially the Extended Status section for Forward_Open failures.

How the Connection Manager relates to other CIP objects

The Connection Manager Object is the gateway, and many other objects participate in connection lifecycle:

• Identity Object (Class 0x01): Electronic keying values validated by Connection Manager during Forward_Open
• Assembly Object (Class 0x04): Assembly instances referenced in Connection Path
• Connection Object (Class 0x05): Instances created/destroyed by the Connection Manager
• TCP/IP Interface Object (Class 0xF5): Provides the network configuration the connections run over
• Ethernet Link Object (Class 0xF6): Provides the link layer the connections run on

This makes the Connection Manager the central coordinator for connection-related logic — the object that orchestrates the others.

For deeper coverage on each:

• CIP Identity Object Explained
• CIP Assembly Object Explained
• CIP TCP/IP Interface Object Explained
• CIP Ethernet Link Object Explained

Frequently asked questions