When a CIP service fails, the device returns an error response with a one-byte General Status Code that tells you why. This page is the complete reference for every code defined by the official CIP specification — what each one means, what usually causes it, and how to fix it.
The codes come straight from ODVA’s CIP Networks Library Volume 1, Appendix B, Edition 3.3. They apply to every CIP network — EtherNet/IP, DeviceNet, ControlNet, CompoNet — because CIP is media-independent. A General Status code returned by a DeviceNet drop and the same code returned by a ControlLogix PLC mean the same thing.
For broader context on how CIP works, see our CIP Protocol Complete Guide.
Table of Contents
Quick reference — the most common codes
If you came here from a specific error code, jump straight to it:
- 0x00 Success
- 0x01 Connection failure
- 0x02 Resource unavailable
- 0x04 Path segment error
- 0x05 Path destination unknown
- 0x08 Service not supported
- 0x09 Invalid attribute value
- 0x0E Attribute not settable
- 0x0F Privilege violation
- 0x10 Device state conflict
- 0x14 Attribute not supported
- 0x15 Too much data
- 0x16 Object does not exist
- 0x1F Vendor specific error
- 0x20 Invalid parameter
- 0x25 Key Failure in path
- 0x26 Path Size Invalid
Where CIP General Status Codes appear
Every CIP request gets a response. A successful response carries data. A failed response carries an Error Response structure containing:
| Field | Size | Purpose |
|---|---|---|
| Reply Service | 1 byte | Original service code with bit 7 set (e.g., Get_Attribute_Single 0x0E becomes 0x8E on error) |
| Reserved | 1 byte | Always 0 |
| General Status | 1 byte | The code in this reference |
| Extended Status Size | 1 byte | Number of 16-bit words in the extended status field |
| Extended Status | Variable | Optional additional detail codes |
The General Status is a single byte. Values 0x00 through 0xFF cover the entire range. The CIP specification defines codes 0x00–0x2B. The range 0x2C–0xCF is reserved for future CIP extensions. The range 0xD0–0xFF is reserved for object class-specific and service-specific errors — each object class can define its own meanings for codes in this range.
Many CIP General Status codes can carry Extended Status values that provide more specific reason information. For example, a Forward_Open returning General Status 0x01 (Connection failure) typically includes Extended Status indicating which exact check failed (out of connections, RPI not supported, ownership conflict, etc.).
Complete CIP General Status Codes table
The full reference, from ODVA Volume 1 Appendix B Table B-1.1:
| Code | Name | Brief description |
|---|---|---|
| 0x00 | Success | Service was successfully performed |
| 0x01 | Connection failure | A connection-related service failed along the connection path |
| 0x02 | Resource unavailable | Resources needed for the requested service were unavailable |
| 0x03 | Invalid parameter value | Use 0x20 instead — 0x03 is deprecated |
| 0x04 | Path segment error | Path segment identifier or syntax was not understood |
| 0x05 | Path destination unknown | Path references an object class, instance, or member that doesn’t exist |
| 0x06 | Partial transfer | Only part of the expected data was transferred |
| 0x07 | Connection lost | The messaging connection was lost |
| 0x08 | Service not supported | The requested service is not implemented for this object |
| 0x09 | Invalid attribute value | Invalid attribute data detected |
| 0x0A | Attribute list error | An attribute in Get/Set_Attribute_List has non-zero status |
| 0x0B | Already in requested mode/state | Object is already in the mode being requested |
| 0x0C | Object state conflict | Object cannot perform service in its current state |
| 0x0D | Object already exists | The instance to be created already exists |
| 0x0E | Attribute not settable | Request to modify a non-modifiable attribute |
| 0x0F | Privilege violation | Permission/privilege check failed |
| 0x10 | Device state conflict | Device’s current state prohibits the service |
| 0x11 | Reply data too large | Response would be larger than the allocated buffer |
| 0x12 | Fragmentation of a primitive value | Operation would fragment a primitive data type |
| 0x13 | Not enough data | Service didn’t supply enough data |
| 0x14 | Attribute not supported | Attribute specified is not supported |
| 0x15 | Too much data | Service supplied more data than expected |
| 0x16 | Object does not exist | Specified object doesn’t exist on the device |
| 0x17 | Service fragmentation sequence not in progress | Fragmentation sequence not active for this data |
| 0x18 | No stored attribute data | Attribute data was not saved prior to the requested service |
| 0x19 | Store operation failure | Attribute save failed during the attempt |
| 0x1A | Routing failure, request packet too large | Request was too large for a network in the path |
| 0x1B | Routing failure, response packet too large | Response was too large for a network in the path |
| 0x1C | Missing attribute list entry data | Service did not supply a required attribute in the list |
| 0x1D | Invalid attribute value list | Returning per-attribute status for invalid values |
| 0x1E | Embedded service error | An embedded service resulted in an error |
| 0x1F | Vendor specific error | Vendor-specific error — see Additional Code Field |
| 0x20 | Invalid parameter | A parameter associated with the request was invalid |
| 0x21 | Write-once value or medium already written | Cannot write to a write-once value that already has data |
| 0x22 | Invalid Reply Received | Invalid reply received (service code mismatch, short reply, etc.) |
| 0x23 | Buffer Overflow | Message larger than receiving buffer can handle |
| 0x24 | Message Format Error | Format of received message not supported by server |
| 0x25 | Key Failure in path | Key Segment doesn’t match the destination module |
| 0x26 | Path Size Invalid | Path size is too small or too large |
| 0x27 | Unexpected attribute in list | Attempt to set an attribute that cannot be set at this time |
| 0x28 | Invalid Member ID | Member ID does not exist in the specified Class/Instance/Attribute |
| 0x29 | Member not settable | Request to modify a non-modifiable member |
| 0x2A | Group 2 only server general failure | DeviceNet Group 2 Only server fallback error |
| 0x2B | Unknown Modbus Error | CIP-to-Modbus translator received an unknown Modbus Exception Code |
| 0x2C–0xCF | Reserved by CIP | Reserved for future extensions |
| 0xD0–0xFF | Object class and service errors | Object-class-specific error range |
Deep dive on the codes you’ll actually see
The codes below cover roughly 90% of the General Status values engineers encounter in the field. Each entry covers what the spec says, what it usually means in practice, and the first few things to check.
0x00 Success
The service was performed successfully. The response carries the requested data (for a Get) or an acknowledgment with no data (for a Set or action). Bit 7 of the Reply Service is NOT set when status is 0x00.
This isn’t an error — it’s the only “good” code in the list. Mentioned here for completeness.
0x01 Connection failure
Spec: A connection-related service failed along the connection path.
What it usually means: Forward_Open or Forward_Close failed. This is the single most common error code engineers see during commissioning. The Extended Status field that comes with 0x01 is where the actual reason lives. Common Extended Status values for 0x01:
- 0x0100 Connection in use or duplicate forward open
- 0x0103 Transport class and trigger combination not supported
- 0x0106 Ownership conflict
- 0x0107 Target connection not found
- 0x0108 Invalid network connection parameter
- 0x0109 Invalid connection size
- 0x0110 Target for connection not configured
- 0x0111 RPI not supported
- 0x0113 Out of connections
- 0x0114 Vendor ID or product code mismatch
- 0x0115 Device type mismatch
- 0x0116 Revision mismatch
- 0x0117 Invalid produced or consumed application path
- 0x0118 Invalid or inconsistent configuration application path
- 0x0119 Non-listen-only connection not opened
- 0x011A Target object out of connections
First things to check:
- Is the device already connected to another scanner? (0x0106 ownership conflict)
- Does the RPI match what the device supports? (0x0111)
- Does the device’s Vendor ID, Product Code, and Revision in the configuration match the actual device? (0x0114–0x0116) — this is electronic keying
- Has the connection slot been freed since the last failed attempt? (sometimes a power cycle of the device clears 0x0100)
0x02 Resource unavailable
Spec: Resources needed for the object to perform the requested service were unavailable.
What it usually means: The device ran out of internal buffers, connections, or memory. Common when a device is being heavily polled or when you have too many connections open.
First things to check: Reduce concurrent connections. Increase RPI to reduce traffic. Check device documentation for stated connection limits.
0x04 Path segment error
Spec: The path segment identifier or the segment syntax was not understood by the processing node.
What it usually means: The class/instance/attribute path you sent doesn’t parse cleanly. Usually a malformed request from a buggy client or a path that uses segment types the device doesn’t support.
First things to check:
- Verify the path encoding in Wireshark — wrong segment type bytes cause this
- Are you using 32-bit Logical Segments on a device that only supports 8-bit? Check the device’s EDS file for supported segment sizes
- Look at the Extended Status to find which byte of the path failed
0x05 Path destination unknown
Spec: The path is referencing an object class, instance, or structure element that is not known or is not contained in the processing node.
What it usually means: You asked for an object that doesn’t exist on this device. The path parsed fine, but the destination is not there.
First things to check:
- Is the Class ID correct for what you’re trying to read? (e.g., requesting Class 0x84 from a device that only has Class 0x01 through 0x10)
- Is the Instance ID valid? Many objects have Instance 1 only — Instance 2 returns 0x05
- Does the device’s EDS file or documentation list the object you’re trying to reach?
- Is your scanner trying to open a connection to an assembly instance that doesn’t exist on this device?
This code is also returned by routing devices when the routed destination cannot be reached.
0x08 Service not supported
Spec: The requested service was not implemented or was not defined for this Object Class/Instance.
What it usually means: The object exists but doesn’t implement the service you asked for. For example, calling Set_Attribute_Single on the Identity Object’s Vendor ID attribute (which is read-only on every CIP device).
First things to check:
- Does the object support this service? Check Volume 1 Chapter 5 for the object’s service table
- Some vendor implementations are minimal and only implement a subset of standard services
- Use Get_Attributes_All (0x01) on the object to see what it actually supports
0x09 Invalid attribute value
Spec: Invalid attribute data detected.
What it usually means: You tried to write a value that’s outside the valid range or format for that attribute. E.g., writing the value 200 to an enumerated attribute that only accepts 0–5.
First things to check:
- Verify the attribute’s valid range — check EDS file or Volume 1 Chapter 5
- Verify data type — writing INT bytes to a UDINT attribute fails this check
- Endianness — CIP is little-endian; if you sent big-endian, the device sees a wildly wrong value
0x0E Attribute not settable
Spec: A request to modify a non-modifiable attribute was received.
What it usually means: The attribute is read-only. Vendor ID, Product Code, Serial Number, firmware revision — these are factory-set and cannot be written.
First things to check:
- Check the attribute’s access rules in the object’s specification (Get-only vs Get/Set)
- Some attributes are settable only in a specific device state — see 0x10 below
0x0F Privilege violation
Spec: A permission/privilege check failed.
What it usually means: The device has access protection enabled and the requester doesn’t have the right privileges. Common when devices use CIP Security or when a password-protected device hasn’t been unlocked.
First things to check:
- Is CIP Security enabled on the device?
- Has the configuration session been authenticated?
- Is “PUT/GET” or equivalent access control disabled?
0x10 Device state conflict
Spec: The device’s current mode/state prohibits the execution of the requested service.
What it usually means: The device is in a state where it won’t accept this service right now. Examples: trying to download firmware while the device is running, trying to modify configuration while a safety connection is active, trying to reset a device that’s in fault.
First things to check:
- Read the Identity Object’s State attribute (Class 0x01, Instance 1, Attribute 8) to see the device’s current state
- Put the device into the correct state before retrying (often “configurable” or “stopped” rather than “running”)
0x14 Attribute not supported
Spec: The attribute specified in the request is not supported.
What it usually means: The Attribute ID you asked for doesn’t exist on this object instance. Often happens when scanning all attributes — you’ll hit gaps where some IDs are not implemented.
First things to check:
- Verify the Attribute ID is valid for this object class (check Volume 1 Chapter 5)
- Some attributes are optional in the spec — vendor may not implement them
- EDS file often lists supported attributes
0x15 Too much data
Spec: The service supplied more data than was expected.
What it usually means: Your write request carried more bytes than the attribute can hold. Sending 4 bytes to a UINT (2-byte) attribute triggers this.
First things to check:
- Verify the attribute’s data type and size
- Check for trailing padding bytes accidentally included
0x16 Object does not exist
Spec: The object specified does not exist in the device.
What it usually means: You asked for an Object Class that the device doesn’t implement. Different from 0x05 (Path destination unknown) — this is specifically when the Class itself isn’t present.
First things to check:
- Read the Message Router Object (Class 0x02) Attribute 1 — Object List — to see all classes the device supports
- Verify your Class ID is correct (e.g., 0x04 for Assembly, 0x01 for Identity)
0x1F Vendor specific error
Spec: A vendor specific error has been encountered. The Additional Code Field of the Error Response defines the particular error encountered.
What it usually means: The device hit an error that doesn’t fit any of the standard CIP categories. The Extended Status carries the actual vendor-defined code.
First things to check:
- Look up the Extended Status code in the device’s manual
- Vendors often define hundreds of specific codes here — Allen-Bradley, Beckhoff, Omron, etc. each have their own catalogs
0x20 Invalid parameter
Spec: A parameter associated with the request was invalid. Used when a parameter does not meet the requirements of this specification and/or the requirements defined in an Application Object Specification.
What it usually means: A field in the request was malformed or out of range. Replaces the older 0x03 (which the spec deprecates in favor of 0x20).
First things to check:
- Verify every parameter value against the spec or device documentation
- Check ranges — many parameters have minimum/maximum constraints
0x25 Key Failure in path
Spec: The Key Segment that was included as the first segment in the path does not match the destination module.
What it usually means: Electronic keying failure. This is the protocol-level enforcement that says “the device I’m talking to must match the device I expected.” If the Vendor ID, Product Code, or Revision in your configuration doesn’t match the actual hardware, you get 0x25.
The Extended Status field tells you which part of the key check failed:
- 0x0114 Vendor ID or Product Code mismatch
- 0x0115 Device Type mismatch
- 0x0116 Revision mismatch
First things to check:
- Did you swap a device for one with a different firmware revision? Update the configuration’s Revision or set keying to “Compatible Module” or “Disable Keying”
- Did the wrong device get installed in the slot?
- Does the EDS in your engineering tool match the device’s actual firmware?
0x26 Path Size Invalid
Spec: The size of the path which was sent with the Service Request is either not large enough to allow the Request to be routed to an object or too much routing data was included.
What it usually means: The Path Size field in the request header doesn’t match the actual path length, or the path is corrupted.
First things to check:
- Look at the request in Wireshark — count actual path bytes versus declared path size
- If you’re building the request manually, verify the path-size word is in 16-bit word units, not bytes
Object-class-specific status codes (0xD0–0xFF)
The range 0xD0 through 0xFF is reserved for object class-specific errors. Each object class can define its own meanings for these codes. So General Status 0xD0 on the Identity Object means something different from 0xD0 on the Connection Manager.
When you see a code in this range, look up the object class first, then check that class’s specification for code definitions. The Volume 1 Chapter 5 entry for each object class lists its object-specific status codes in the “Object-specific General and Extended Status Codes” subsection.
This range gives object designers freedom to define rich error semantics without exhausting the CIP-reserved code space.
Forward_Open status codes — a special case
Forward_Open is the service every I/O connection starts with, and it has the richest set of failure modes. Almost every Forward_Open failure returns General Status 0x01 (Connection failure), but the Extended Status is what tells you the real story. The most common Extended Status values for Forward_Open failures:
| Extended Status | Reason | Common cause |
|---|---|---|
| 0x0100 | Connection in use or duplicate forward open | Existing connection from this originator still active |
| 0x0103 | Transport class and trigger combination not supported | Wrong transport class for this object |
| 0x0106 | Ownership conflict | Another scanner already owns this connection |
| 0x0107 | Target connection not found | Connection slot doesn’t exist on target |
| 0x0108 | Invalid network connection parameter | Connection parameters malformed |
| 0x0109 | Invalid connection size | Data size doesn’t match assembly instance |
| 0x0110 | Target for connection not configured | Target object exists but isn’t ready for connection |
| 0x0111 | RPI not supported | Update rate outside target’s supported range |
| 0x0113 | Out of connections | Target has no available connection resources |
| 0x0114 | Vendor ID or product code mismatch | Electronic keying failed |
| 0x0115 | Device type mismatch | Electronic keying failed |
| 0x0116 | Revision mismatch | Electronic keying failed |
| 0x0117 | Invalid produced or consumed application path | Assembly instance ID doesn’t exist |
| 0x0118 | Invalid or inconsistent configuration application path | Configuration assembly mismatch |
When debugging Forward_Open failures, always read both General Status (almost always 0x01) and Extended Status — the Extended Status is where the actionable diagnosis lives.
How CIP General Status differs from encapsulation status
EtherNet/IP layers two error mechanisms on top of each other. Engineers troubleshooting need to know which is which:
| Layer | Status mechanism | Range | Where it appears |
|---|---|---|---|
| CIP application | General Status Codes (this reference) | 0x00–0xFF | Inside the CIP reply, after the encapsulation header |
| EtherNet/IP encapsulation | Encapsulation Status Codes | 0x0000–0x0069 | In the 24-byte encapsulation header itself |
A successful encapsulation transaction (Status 0x0000 in the header) can wrap a failed CIP service (General Status 0x05, 0x14, etc.). And a successful CIP service (General Status 0x00) is the normal case after a successful encapsulation transaction (Status 0x0000).
Encapsulation-level errors typically mean the message couldn’t be delivered to the CIP layer at all (wrong session handle, invalid command, malformed packet). CIP-level errors mean the message reached the CIP application but the service couldn’t be performed.
For the encapsulation-level codes, see our EtherNet/IP Encapsulation Protocol Explained article.
Reading CIP status codes in Wireshark
Wireshark’s CIP dissector decodes General Status codes automatically. Useful filters:
cip # All CIP traffic
cip.genstat != 0 # Only failed CIP responses
cip.genstat == 0x01 # Only connection failures
cip.genstat == 0x05 # Only path destination unknown
cip.genstat == 0x25 # Only electronic keying failures
cip.service == 0xCB # Only Forward_Open replies (0x4B + reply bit)
cip.ext_status # Frames that include extended statusA common diagnostic workflow: capture during the problem, apply cip.genstat != 0 to find every error in the session, then expand each to read the General Status and any Extended Status. For Forward_Open errors specifically, filter on cip.service == 0xCB to find all the connection-establishment replies.
For more on Wireshark with EtherNet/IP, see our Wireshark for EtherNet/IP guide.
Practical troubleshooting workflow
When a CIP error appears, work through it in this order:
- Identify the layer. Is this an encapsulation error (in the header) or a CIP error (inside the payload)? Different fixes.
- Read the General Status. Match against this reference to understand the category of failure.
- Read the Extended Status if present. This is where the specific reason lives for codes like 0x01 and 0x1F.
- Identify the object and service. What was being requested? Is it valid for this device?
- Check the device state. Many failures (0x10, 0x0E, 0x0C) depend on the device’s current mode.
- Check the configuration. Many failures (0x25, 0x114-0x116, 0x117) come from configuration mismatches.
- Capture in Wireshark. If the spec doesn’t immediately explain what’s happening, the actual bytes always will.
Frequently asked questions
What are CIP General Status Codes?
CIP General Status Codes are one-byte values that appear in the response to every CIP service request, indicating whether the service succeeded (0x00) or failed (any non-zero value). The codes are defined in ODVA’s CIP Networks Library Volume 1, Appendix B and apply across all CIP networks — EtherNet/IP, DeviceNet, ControlNet, and CompoNet.
What is CIP General Status 0x01?
General Status 0x01 means “Connection failure” — a connection-related service (typically Forward_Open or Forward_Close) failed along the connection path. The specific reason is carried in the Extended Status field that accompanies the 0x01 General Status. Common reasons include ownership conflict (0x0106), RPI not supported (0x0111), out of connections (0x0113), and electronic keying mismatches (0x0114-0x0116).
What is CIP General Status 0x05?
General Status 0x05 means “Path destination unknown” — the request referenced an Object Class, Instance, or member that does not exist on the device. This is different from 0x16 (Object does not exist), which specifically means the Object Class is not implemented. 0x05 covers cases where the class exists but the specific Instance or member doesn’t.
What is CIP General Status 0x25?
General Status 0x25 means “Key Failure in path” — electronic keying failed. The Key Segment in the request specified a Vendor ID, Product Code, Device Type, or Revision that doesn’t match the actual device. To fix it, update your configuration to match the installed device, or change electronic keying mode to “Compatible Module” or “Disable Keying” in your engineering tool.
What is the difference between General Status 0x14 and 0x05?
General Status 0x14 (Attribute not supported) means the Object Class and Instance exist but the specific Attribute ID is not implemented. General Status 0x05 (Path destination unknown) means the Class or Instance itself is missing. So 0x14 is “the data field doesn’t exist” and 0x05 is “the object doesn’t exist.”
What is the difference between CIP General Status and Extended Status?
General Status is a one-byte code defined by the CIP specification (0x00 through 0x2B, plus reserved ranges). Extended Status is one or more 16-bit values that follow General Status to provide more specific reason information. For codes like 0x01 (Connection failure) and 0x1F (Vendor specific error), the Extended Status is where the actual diagnostic information lives — General Status alone is not enough to troubleshoot.
How are CIP General Status codes different from EtherNet/IP encapsulation status codes?
Encapsulation status codes (0x0000–0x0069, defined in Volume 2 Chapter 2) appear in the 24-byte encapsulation header and indicate errors at the TCP/IP transport level — wrong session handle, malformed encapsulation header, etc. CIP General Status codes appear inside the encapsulated CIP reply and indicate errors at the application level — wrong object, wrong service, invalid value. The two are independent: an encapsulation success can wrap a CIP failure, and vice versa.
What does the 0xD0-0xFF range of General Status codes mean?
The 0xD0 through 0xFF range is reserved for object-class-specific errors. Each object class can define its own meanings for codes in this range. So a status code of 0xD0 on the Identity Object means something different from 0xD0 on the Connection Manager. To interpret these codes, check the specification for the specific object class that returned them.
Where can I find the official CIP General Status Codes specification?
The codes are documented in ODVA’s CIP Networks Library Volume 1: Common Industrial Protocol (CIP) Specification, Appendix B: Status Codes. The current published edition is Edition 3.3 (2007). ODVA members can access the full specification at odva.org.
Are CIP General Status codes the same across EtherNet/IP, DeviceNet, and ControlNet?
Yes. CIP is media-independent, and General Status codes are part of the CIP common specification (Volume 1), not the network-specific adaptations (Volumes 2, 3, 4, 6). A code 0x05 returned by a DeviceNet drop, a ControlNet device, and an EtherNet/IP I/O block all mean the same thing: Path destination unknown.
Why does my Forward_Open return General Status 0x01?
Because Forward_Open is a connection-related service, almost every Forward_Open failure returns General Status 0x01 (Connection failure). The actual reason is in the Extended Status field. Common Extended Status values include 0x0106 (ownership conflict), 0x0111 (RPI not supported), 0x0113 (out of connections), and 0x0114-0x0116 (electronic keying mismatches). Always read both General Status and Extended Status when troubleshooting Forward_Open failures.