Every CIP message starts with a one-byte service code. That byte tells the target device what to do — read an attribute, write an attribute, open a connection, reset, save configuration. This page is the authoritative reference for every CIP service code defined by ODVA’s CIP Networks Library Volume 1, Appendix A.
If services are the verbs of CIP, this article is the verb dictionary. If you’re decoding a Wireshark capture and need to know what service code 0x0A does, or you’re reading a Studio 5000 error log that mentions service 0x4B, this is your reference.
For broader context on how CIP works, see our CIP Protocol Complete Guide. For the error codes services return when they fail, see our CIP General Status Codes Reference.
Table of Contents
Quick jump — the services you’ll actually see
- 0x01 Get_Attributes_All
- 0x02 Set_Attributes_All
- 0x05 Reset
- 0x0A Multiple_Service_Packet
- 0x0E Get_Attribute_Single
- 0x10 Set_Attribute_Single
- 0x4B Forward_Open
- 0x4E Forward_Close
- 0x52 Unconnected_Send
- 0x54 Large_Forward_Open
What CIP service codes are
A CIP request message has a clean structure:
| Service Code (1 byte) | Request Path Size (1 byte) | Request Path (variable) | Service Data (variable) |The service code is always the first byte. Everything else describes which object the service acts on and what data the service needs.
The reply mirrors the request with one critical change — the reply service code is the request service code with bit 7 (MSB) set. So:
- Request Get_Attribute_Single = 0x0E
- Reply Get_Attribute_Single = 0x8E
This bit-7 convention lets a receiver immediately distinguish requests from replies on a single wire. When you see service code 0x8E in Wireshark, it’s a reply to a Get_Attribute_Single request.
How CIP services are organized
The service code space is divided into ranges:
| Range | Category | Purpose |
|---|---|---|
| 0x00–0x31 | CIP Common Services | Defined by Volume 1 Appendix A — work on most object classes |
| 0x32–0x4A | Object class-specific | Each object class defines its own services in this range |
| 0x4B–0x7F | Object class-specific (continued) | Includes Connection Manager services like Forward_Open |
| 0x80–0xFF | Reply service codes | These are responses to the corresponding request codes (with bit 7 set) |
So when you see 0x0E in a CIP message, it’s Get_Attribute_Single (a Common Service). When you see 0x4B, it’s a Connection Manager-specific service (Forward_Open). When you see 0x8E, it’s a Get_Attribute_Single reply.
This division means a vendor designing a new object class can define their own custom services in the 0x32–0x7F range without colliding with Common Services. The Common Services range is owned by ODVA; the object-specific range is owned by whoever owns the object class.
CIP Common Services — complete table
From ODVA Volume 1 Appendix A Table A-3.1, the complete list of CIP Common Service codes:
| Code | Service Name | Purpose |
|---|---|---|
| 0x00 | (Reserved) | Reserved for future use |
| 0x01 | Get_Attributes_All | Read every attribute of an instance or class in one transaction |
| 0x02 | Set_Attributes_All | Write all attributes of an instance or class in one transaction |
| 0x03 | Get_Attribute_List | Read a list of selected attributes by ID |
| 0x04 | Set_Attribute_List | Write a list of selected attributes by ID |
| 0x05 | Reset | Reset the object — typically returns to default state |
| 0x06 | Start | Start the object’s behavior |
| 0x07 | Stop | Stop the object’s behavior |
| 0x08 | Create | Create a new instance of the object class |
| 0x09 | Delete | Delete an instance |
| 0x0A | Multiple_Service_Packet | Bundle several services into one transaction |
| 0x0B–0x0C | (Reserved) | Reserved for future use |
| 0x0D | Apply_Attributes | Apply pending attribute changes |
| 0x0E | Get_Attribute_Single | Read one specific attribute |
| 0x0F | (Reserved) | Reserved for future use |
| 0x10 | Set_Attribute_Single | Write one specific attribute |
| 0x11 | Find_Next_Object_Instance | Locate the next instance of an object |
| 0x12–0x13 | (Reserved) | Reserved for future use |
| 0x14 | Error Response | DeviceNet-only — used in error replies on DeviceNet |
| 0x15 | Restore | Restore previously saved attribute data |
| 0x16 | Save | Save current attribute data to non-volatile storage |
| 0x17 | No Operation (NOP) | No-op — used for testing or keep-alive |
| 0x18 | Get_Member | Read a member of a structured attribute |
| 0x19 | Set_Member | Write a member of a structured attribute |
| 0x1A | Insert_Member | Insert a new member into a structured attribute |
| 0x1B | Remove_Member | Remove a member from a structured attribute |
| 0x1C | GroupSync | Group synchronization service |
| 0x1D–0x31 | (Reserved) | Reserved for additional Common Services |
The four bolded services — Get_Attribute_Single, Set_Attribute_Single, Get_Attributes_All, Set_Attributes_All — handle the vast majority of CIP configuration and diagnostic traffic in production systems. Multiple_Service_Packet is the go-to optimization when a client needs to do many small operations efficiently. Reset is the most common state-machine service.
Deep dive on the services you’ll actually use
0x01 Get_Attributes_All
Spec: Returns the contents of the instance or class attributes defined in the object definition.
What it does: Reads every attribute of an instance (or class) in a single transaction. The device packs all its attributes into one response in the order defined by the object specification.
Request structure: Just the service code and the path. No service data.
Response structure: Object-defined byte stream containing all attributes in spec-defined order.
When to use it: Initial device inventory, populating a configuration tool, getting a snapshot of an object’s state. Far more efficient than reading attributes one at a time.
Watch out for: If the device implements only some attributes, the response is shorter than expected. The spec says clients should assume default values for missing attributes at the end. If a missing attribute lands in the middle of the response, the response data is in error and should be discarded.
Common usage: Reading the Identity Object (Class 0x01) Instance 1 with Get_Attributes_All returns Vendor ID, Device Type, Product Code, Revision, Status, Serial Number, Product Name, and State — everything you need to identify the device in one transaction.
0x02 Set_Attributes_All
Spec: Modifies the contents of the instance or class attributes defined in the object definition.
What it does: Writes all attributes of an instance in a single transaction. The data must be in the exact order and format defined by the object specification.
Request structure: Object-defined byte stream containing all settable attributes.
Response structure: Status only — no data.
When to use it: Bulk configuration write where you want to set everything in one shot.
Watch out for: All settable attributes must be present in the request — if any are missing, the request fails. If any single attribute value fails validation, the entire Set_Attributes_All is rejected and returns Status 0x09 (Invalid attribute value) with the Additional Code identifying which attribute failed first.
0x05 Reset
Spec: Invokes the Reset service of the specified Class/Object. Typically this would cause a transition to a default state or mode.
What it does: Forces the object (or device) into its default state. On the Identity Object (Class 0x01), Reset reboots the entire device.
Request structure: Optional object-specific parameters. Some Reset services accept a parameter indicating the type of reset (e.g., 0 = reset state, 1 = reset to factory defaults).
Response structure: Status only.
Important behavior from the spec: If the Reset will leave the object in a state where it cannot respond, the device must respond before executing the reset. This is how a “reboot the device” Reset works — the device sends the reply, then reboots. The reply confirms the command was received, even though the device goes offline immediately afterward.
Common usage: Reset on Identity Object Instance 1 to reboot the device. Reset on the Identity Object with parameter 1 to factory-default the device. Reset on a Connection Object to drop a stuck connection.
0x0A Multiple_Service_Packet
Spec: Service that bundles several other services into a single transaction.
What it does: The Message Router Object (Class 0x02) implements this service. The request contains a count of embedded services and the offset to each one. The response contains the corresponding individual replies.
Why this matters: Network round-trip time often dominates configuration performance. Reading 50 separate attributes with 50 separate Get_Attribute_Single calls takes 50 round-trips. Bundling them into one Multiple_Service_Packet takes one round-trip. Studio 5000, RSLinx, and most configuration tools use this aggressively under the hood.
Watch out for: The response gets large fast. Hit Status 0x11 (Reply data too large) if you bundle too much. The size limit is the smaller of the device’s connection size and the encapsulation packet limit.
0x0E Get_Attribute_Single
Spec: The Get_Attribute_Single service shall return the contents of a single attribute.
What it does: Reads one attribute. The path identifies Class, Instance, and Attribute. The response carries just that attribute’s value.
Request structure: Service code + path to Class/Instance/Attribute. No service data.
Response structure: Just the attribute’s value as a byte stream.
When to use it: Almost always. Get_Attribute_Single is the workhorse of CIP. Almost every configuration tool’s “read this value” operation issues a Get_Attribute_Single underneath.
Example: Service 0x0E, Class 0x01, Instance 1, Attribute 7 reads the Product Name of any CIP device.
0x10 Set_Attribute_Single
Spec: The Set_Attribute_Single service shall modify the contents of a single attribute.
What it does: Writes one attribute. The path identifies Class, Instance, and Attribute. The service data carries the new value.
Request structure: Service code + path + new value.
Response structure: Status only.
When to use it: Almost always for writes. Like its Get sibling, Set_Attribute_Single is the workhorse. Configuration tools use it for “change this value” operations.
Common errors:
- 0x0E (Attribute not settable) — read-only attribute
- 0x09 (Invalid attribute value) — value out of range or wrong type
- 0x14 (Attribute not supported) — Attribute ID doesn’t exist
- 0x10 (Device state conflict) — device won’t accept changes in its current state
Critical object-specific services
The Common Services above are defined by ODVA in Appendix A. Below this range, individual object classes define their own services. The Connection Manager Object (Class 0x06) defines the most commonly seen object-specific services.
0x4B Forward_Open
What it does: Establishes a CIP connection. This is the service every I/O connection starts with. The originator sends Forward_Open to the target’s Connection Manager Object (Class 0x06) specifying connection parameters. If the target accepts, a Connection ID is returned and cyclic exchange begins.
Request carries: Connection priority, transport class, trigger type, RPI (Requested Packet Interval), timeout multiplier, network connection parameters (size, type, redundant owner), connection path (which Assembly objects to use), electronic keying segment.
Response carries: OT (originator-to-target) Connection ID, TO (target-to-originator) Connection ID, OT API (Actual Packet Interval), TO API.
Why it matters: Forward_Open is the most-watched service in any EtherNet/IP capture. Every cyclic I/O connection starts here. Every connection failure shows up as a Forward_Open returning General Status 0x01 with an Extended Status that explains why.
0x4E Forward_Close
What it does: Closes a CIP connection. The originator sends Forward_Close to the same Connection Manager that received the Forward_Open. The connection is torn down, resources are freed, and no further cyclic data flows.
Request carries: Connection serial number, originator vendor ID and serial number, connection path.
Response carries: Status only.
Common usage: Issued when a PLC is removed from a configuration, when a tool finishes its session, or when a connection is being reconfigured. Issuing Forward_Close cleanly is preferable to letting connections time out — the latter takes longer to free resources on the target.
0x52 Unconnected_Send
What it does: Sends a CIP message through the network without first opening a connection. The Connection Manager uses this for explicit messaging across multiple network hops — for example, a ControlLogix PLC on EtherNet/IP reading a parameter from a DeviceNet drive through a 1756-DNB scanner.
Request carries: Timeout, embedded service request (the actual CIP message being sent), route path (the network hops to reach the destination).
Response carries: The reply from the destination, returned through the same route.
When to use it: Cross-network explicit messaging. For same-network unconnected messaging, the simpler UCMM mechanism is used at the encapsulation layer.
0x54 Large_Forward_Open
What it does: Same as Forward_Open but with larger fields to support data sizes beyond the standard Forward_Open’s 16-bit limit. Used when a connection’s data size exceeds 511 bytes.
Why it exists: Original Forward_Open used 16-bit network connection parameters with a 9-bit size field — limiting connections to 511 bytes. Large_Forward_Open uses 32-bit parameters supporting much larger connections, which is necessary for modern PLCs that exchange large structured data over single I/O connections.
When to use it: Generally handled automatically by the engineering tool. If your tool reports “connection size exceeds Forward_Open limit,” it will switch to Large_Forward_Open internally.
Request and reply service codes — bit 7
This is the rule worth memorizing. Every CIP reply has the same service code as the corresponding request, but with bit 7 set:
| Request | Reply | Description |
|---|---|---|
| 0x01 | 0x81 | Get_Attributes_All |
| 0x02 | 0x82 | Set_Attributes_All |
| 0x05 | 0x85 | Reset |
| 0x0A | 0x8A | Multiple_Service_Packet |
| 0x0E | 0x8E | Get_Attribute_Single |
| 0x10 | 0x90 | Set_Attribute_Single |
| 0x4B | 0xCB | Forward_Open |
| 0x4E | 0xCE | Forward_Close |
| 0x52 | 0xD2 | Unconnected_Send |
| 0x54 | 0xD4 | Large_Forward_Open |
When you see service code 0xCB in Wireshark, it’s a Forward_Open reply. When you see 0x8E, it’s a Get_Attribute_Single reply. The bit-7 convention works for every service code in the protocol.
The reply tells the receiver:
- Status 0x00 → Success, the response service data carries the requested information
- Status non-zero → Failure, the response service data carries the error information
Services by use case
Different jobs call for different services. Here’s a cheat sheet:
Device discovery and identification
- 0x01 Get_Attributes_All on Identity Object — full device info in one shot
- 0x0E Get_Attribute_Single on Identity Object Attribute 7 — Product Name only
- 0x0E Get_Attribute_Single on Identity Object Attribute 6 — Serial Number only
Configuration
- 0x10 Set_Attribute_Single — change one parameter
- 0x02 Set_Attributes_All — bulk parameter set
- 0x16 Save — commit configuration to non-volatile storage
- 0x15 Restore — load previously saved configuration
I/O connection establishment
- 0x4B Forward_Open — open standard I/O connection
- 0x54 Large_Forward_Open — open large I/O connection (>511 byte data)
- 0x4E Forward_Close — close I/O connection
Cross-network explicit messaging
- 0x52 Unconnected_Send — send a one-shot CIP message across network boundaries
Bulk efficient operations
- 0x0A Multiple_Service_Packet — bundle many small operations into one round-trip
Device control
- 0x05 Reset — reset object or device
- 0x06 Start — start object behavior
- 0x07 Stop — stop object behavior
Structured attribute access
- 0x18 Get_Member — read one member of a structured attribute
- 0x19 Set_Member — write one member of a structured attribute
- 0x1A Insert_Member — add a member to a structured attribute
- 0x1B Remove_Member — remove a member from a structured attribute
Reading service codes in Wireshark
Wireshark’s CIP dissector decodes service codes automatically. Useful filters:
cip # All CIP traffic
cip.service == 0x01 # Get_Attributes_All requests
cip.service == 0x0E # Get_Attribute_Single requests
cip.service == 0x10 # Set_Attribute_Single requests
cip.service == 0x4B # Forward_Open requests
cip.service == 0x4E # Forward_Close requests
cip.service == 0x52 # Unconnected_Send
cip.service == 0xCB # Forward_Open replies
cip.service == 0x8E # Get_Attribute_Single replies
cip.service == 0x0A # Multiple_Service_PacketA useful diagnostic pattern: filter on cip.service == 0x4B to find every connection-open attempt in a capture. Each one will be followed by a cip.service == 0xCB reply. If the reply carries cip.genstat != 0, that connection failed and the Extended Status carries the reason.
For broader EtherNet/IP capture workflows, see our Wireshark for EtherNet/IP guide.
Common errors associated with each service
When a service fails, it returns a General Status Code. Some failures are tied to specific services:
| Service | Common error | What it usually means |
|---|---|---|
| 0x0E Get_Attribute_Single | 0x14 (Attribute not supported) | Attribute ID doesn’t exist on this object |
| 0x10 Set_Attribute_Single | 0x0E (Attribute not settable) | Attribute is read-only |
| 0x10 Set_Attribute_Single | 0x09 (Invalid attribute value) | Value out of range or wrong type |
| 0x01 Get_Attributes_All | 0x08 (Service not supported) | Object doesn’t implement this service |
| 0x4B Forward_Open | 0x01 + Extended 0x0106 | Connection ownership conflict |
| 0x4B Forward_Open | 0x01 + Extended 0x0111 | RPI not supported |
| 0x4B Forward_Open | 0x01 + Extended 0x0113 | Out of connections |
| 0x4B Forward_Open | 0x01 + Extended 0x0114-0x0116 | Electronic keying failure |
| 0x05 Reset | 0x10 (Device state conflict) | Device can’t reset from its current state |
| 0x02 Set_Attributes_All | 0x14 (Attribute not supported) | Some required settable attribute isn’t implemented |
| 0x16 Save | 0x19 (Store operation failure) | NVRAM write failed |
| 0x0A Multiple_Service_Packet | 0x11 (Reply data too large) | Bundled responses exceed buffer |
Frequently asked questions
What is a CIP service code?
A CIP service code is a one-byte value in every CIP request and reply that identifies which operation is being performed. Examples include 0x0E (Get_Attribute_Single), 0x10 (Set_Attribute_Single), and 0x4B (Forward_Open). Codes 0x00–0x31 are CIP Common Services defined by ODVA in Volume 1 Appendix A. Codes 0x32 and above are object class-specific.
What is the difference between Get_Attribute_Single and Get_Attributes_All?
Get_Attribute_Single (0x0E) reads one specific attribute identified by Class, Instance, and Attribute ID. Get_Attributes_All (0x01) reads every attribute of an instance in one transaction, returning them in the order defined by the object specification. Get_Attributes_All is more efficient for snapshot operations; Get_Attribute_Single is preferred when you only need one value.
What service code is Forward_Open?
Forward_Open is service code 0x4B. It is implemented by the Connection Manager Object (Class 0x06). The reply service code is 0xCB (0x4B with bit 7 set). Every CIP I/O connection begins with a Forward_Open request, making it one of the most important services in the protocol.
What does service code 0x4B mean?
Service code 0x4B is Forward_Open — the service used to establish a CIP connection. The request includes the connection parameters (RPI, transport class, electronic keying, connection size, application path). If accepted, the response carries the assigned Connection IDs for cyclic I/O exchange.
What is the difference between request and reply service codes?
The reply service code is the request service code with bit 7 (the most significant bit) set. So Get_Attribute_Single request 0x0E becomes reply 0x8E. Forward_Open request 0x4B becomes reply 0xCB. This convention lets receivers immediately distinguish requests from replies on a single wire.
What is Multiple_Service_Packet?
Multiple_Service_Packet is service code 0x0A, implemented by the Message Router Object (Class 0x02). It lets a client bundle multiple CIP service requests into a single transaction, dramatically reducing network round-trip overhead. Studio 5000 and RSLinx use it heavily to optimize configuration access.
What does service code 0x0E do?
Service code 0x0E is Get_Attribute_Single — it reads one attribute from a CIP object. The request specifies the Class ID, Instance ID, and Attribute ID. The response carries the attribute’s current value. This is the most common service in CIP traffic — almost every “read a value” operation uses it.
What service code is Set_Attribute_Single?
Set_Attribute_Single is service code 0x10. It writes a value to a single CIP attribute identified by Class, Instance, and Attribute ID. The reply service code is 0x90. Common errors include 0x0E (Attribute not settable) for read-only attributes and 0x09 (Invalid attribute value) for out-of-range values.
What is the difference between Forward_Open and Large_Forward_Open?
Forward_Open (0x4B) supports connections with data sizes up to 511 bytes. Large_Forward_Open (0x54) uses larger network connection parameter fields to support connections with much larger data sizes. Modern PLCs exchanging large structured data over single I/O connections typically use Large_Forward_Open. The engineering tool selects which one to use automatically based on the configured connection size.
Where can I find the official CIP service codes specification?
The CIP Common Services are defined in ODVA’s CIP Networks Library Volume 1: Common Industrial Protocol (CIP) Specification, Appendix A: Explicit Messaging Services. Object-specific services (codes 0x32 and above) are defined in Chapter 5 of the same volume under each object class definition. The current edition is 3.3 (2007). ODVA members can access the full specification at odva.org.
Are CIP service codes the same across EtherNet/IP, DeviceNet, and ControlNet?
Yes. CIP is media-independent, and service codes are part of the CIP common specification (Volume 1), not the network-specific adaptations (Volumes 2, 3, 4, 6). A Get_Attribute_Single request (0x0E) issued to a DeviceNet drop, a ControlNet device, or an EtherNet/IP I/O block all mean the same thing.
What does service code 0xCB mean in Wireshark?
0xCB is the reply to a Forward_Open request (0x4B with bit 7 set). When you see 0xCB in Wireshark, you’re looking at a Forward_Open reply. If the General Status field is 0x00, the connection opened successfully and the response carries the assigned Connection IDs. If General Status is non-zero (typically 0x01), the connection failed and Extended Status carries the reason.