CIP Path Segments Explained: EPATH Encoding for Engineers

Open any CIP packet in Wireshark and you’ll see paths encoded as hex bytes — 20 04 24 66 2C 67 2C 68, 20 06 24 01, 34 04 01 00 0C 00 B8 00 04 01. These are CIP path segments — the universal addressing format that tells every CIP service where to go. Class IDs, Instance IDs, Attribute IDs, routing paths across networks, symbolic tag names, electronic keying values — everything that points to an object in CIP uses path segments.

This article is the engineer’s guide to decoding these bytes. Every segment type, every format, with worked examples engineers can apply when looking at real captures. Built from ODVA’s CIP Networks Library Volume 1, Appendix C — the authoritative source for path encoding.

For broader CIP context, see the CIP Protocol Complete Guide and the CIP Data Types Complete Reference.

What CIP path segments are in one paragraph

A CIP path (data type EPATH) is a sequence of segments that reference an entity in a CIP network — typically an object’s Class, Instance, and Attribute, plus any routing information to reach a target across multiple networks. Per Volume 1 Section C-1, a CIP segment is a stream of encoded items used to reference, describe, and/or configure a CIP entity. The first byte of every segment is a Segment Type/Format byte whose top three bits identify which kind of segment it is. Five segment types exist: Port (routing), Logical (object addressing), Network (network parameters), Symbolic (string names), and Data (embedded data). Paths combine multiple segments to form complete references — the format used in every Forward_Open Connection Path, every Get_Attribute_Single path, every Unconnected_Send route path.

The Segment Type/Format byte

The first byte of every segment encodes both the segment type and the segment format. Per Volume 1 Figure C-1.2:

Bit:    7   6   5   4   3   2   1   0
       └─Type─┘   └────Format─────┘

The top 3 bits (bits 7-5) identify the segment type:

The remaining 5 bits (bits 4-0) form the segment format — interpreted differently for each segment type.

This single-byte design lets a parser look at one byte and immediately know how many more bytes to read and how to interpret them.

The five segment types at a glance

Per Volume 1 Section C-1.1:

Almost every CIP path you’ll see in Wireshark uses Logical Segments. Multi-network installations also use Port Segments. The other three are specialty cases.

Logical Segment

The most important segment type. Used to specify the Class, Instance, Attribute, Connection Point, or Member of an object. Per Volume 1 Section C-1.4.2:

Bit:    7   6   5   4   3   2   1   0
       └─Type─┘ └Log─Type┘ └Log─Fmt┘
       └─001─┘

Logical Type (bits 4-2)

Logical Format (bits 1-0)

The most common segment bytes

Combining Logical Type + Logical Format gives you the segment bytes engineers see everywhere:

Once you memorize these handful of bytes, decoding CIP paths in Wireshark becomes trivial.

Worked example — Class 5, Instance 2, Attribute 1

Per Volume 1 Figure C-1.5, the path “Class 5, Instance 2, Attribute 1” encodes as:

20 05 24 02 30 01
└─┬─┘ └─┬─┘ └─┬─┘
 Class  Inst  Attr

Breaking it down byte by byte:

• 20 = Logical Segment, Class ID, 8-bit format
• 05 = the value 5 (Class 5)
• 24 = Logical Segment, Instance ID, 8-bit format
• 02 = the value 2 (Instance 2)
• 30 = Logical Segment, Attribute ID, 8-bit format
• 01 = the value 1 (Attribute 1)

This 6-byte EPATH appears at the start of every Get_Attribute_Single request that targets a single attribute somewhere in the device.

Worked example — Forward_Open Connection Path

A typical Forward_Open to a Point I/O block has a Connection Path like:

20 04 24 66 2C 67 2C 68
└─┬─┘ └─┬─┘ └─┬─┘ └─┬─┘
 Class  Cfg  Cons  Prod
0x04   Inst 102 Inst 103 Inst 104
(Asm)  (Conf)  (Cons)  (Prod)

Decoded:

• 20 04 = Class 0x04 (Assembly Object)
• 24 66 = Instance 0x66 (102) — Configuration assembly
• 2C 67 = Connection Point 0x67 (103) — Consumed (output) assembly
• 2C 68 = Connection Point 0x68 (104) — Produced (input) assembly

The same encoding appears in nearly every EtherNet/IP I/O Forward_Open. Different devices use different instance numbers; the segment types stay the same.

16-bit Class ID example

When the Class ID exceeds 255, you need a 16-bit logical format. Per Volume 1 Figure C-1.6:

Packed EPATH with 16-bit Class:

21 05 00 24 02 30 01
└──┬──┘ └─┬─┘ └─┬─┘
 Class   Inst  Attr
 (0x0005 LE)

Padded EPATH with 16-bit Class: (note the pad byte after 21)

21 00 05 00 24 02 30 01
   ▲
   pad byte for word alignment

The pad byte (00) appears in Padded EPATHs to keep 16-bit and 32-bit logical values word-aligned. Packed EPATHs omit the pad. We cover this distinction more in the Padded vs Packed Paths section.

Electronic Key Segment (Special Logical)

The Electronic Key Segment is encoded as a Special Logical Type — segment byte 34. Per Volume 1 Table C-1.3:

Worked example for a Rockwell 1734-AENT Point I/O Adapter at firmware 4.001:

34 04 01 00 0C 00 B8 00 04 01
└┬┘└┬┘└──┬──┘└──┬──┘└──┬──┘└┬┘└─┬─┘
Key Fmt Vend  DevType ProdC Maj Min
       =1   =0x0C    =0xB8  =4  =1
                    
0x34 = Electronic Key segment
0x04 = Key Format value 4
0x0001 = Vendor ID 1 (Rockwell, little-endian)
0x000C = Device Type 12 (Communications Adapter, little-endian)
0x00B8 = Product Code 184 (little-endian)
0x04 = Major Revision 4 (bit 7 clear = strict matching)
0x01 = Minor Revision 1

This 10-byte segment appears at the start of Forward_Open Connection Paths to validate that the actual device matches the configuration. Mismatches return General Status 0x01 with Extended Status 0x0114 (Vendor ID or Product Code), 0x0115 (Device Type), or 0x0116 (Revision) — the famous “electronic keying failure.”

The Compatibility bit (bit 7 of Major Revision byte) controls how strict the keying is:

• 0 = strict match — exact values required
• 1 = compatibility match — any device the target can emulate is accepted

For more on electronic keying failures, see our CIP General Status Codes Reference.

Port Segment

The Port Segment routes a message across a subnet boundary. Per Volume 1 Section C-1.4.1, it identifies:

• Which communication port to leave through
• The link address of the next device

Bit:    7   6   5   4         3   2   1   0
       └─Type─┘ │ExtLink│    └──Port ID──┘
       └─000─┘ │  Size  │

The Port Segment format byte structure:

• Bits 7-5: Segment Type = 000 (Port Segment)
• Bit 4: Extended Link Address Size flag (0 = 1-byte address, 1 = extended)
• Bits 3-0: Port Identifier

Common Port Segment values

A common example: a 1756-EN2T module in slot 0 of a 1756 chassis routes a message to a controller in slot 2. The Port Segment is:

01 02
└┬┘└┬┘
Port Link
 1   2
(Back- (slot
 plane)  2)

Decoded:

• 01 = Port Segment, Port Identifier = 1 (Backplane), 1-byte link address
• 02 = Link address = 2 (slot 2)

Combined with the rest of the path to address the controller’s Identity Object:

01 02 20 01 24 01
└─┬─┘ └─┬─┘ └─┬─┘
Port  Class Inst
1→2   0x01  1

This means: “Route through Backplane port to slot 2, then read Class 0x01 (Identity), Instance 1.”

Network Segment

The Network Segment specifies parameters that may be required by a node to transmit a message across a network. Per Volume 1 Section C-1.4.3, it must immediately precede the Port Segment it applies to.

Bit:    7   6   5   4       3   2   1   0
       └─Type─┘ │SubType│   └──Network Subtype──┘
       └─010─┘ │ Format │

Bit 4 (Subtype Format):

• 0 = Single byte of data follows
• 1 = Number of data words (one byte) then variable data

Network Subtype values (bits 3-0 when bit 4 = 1):

Production Inhibit Time Network Segment

A practical use of Network Segments. Per Volume 1 Section C-1.4.3.3, this segment specifies the minimum time (in milliseconds) between successive transmissions of connected data — preventing producers from sending too fast even if data changes rapidly.

43 01 0A
└┬┘└┬┘└┬┘
Type Sub Data
Net  PIT  10 ms

Decoded:

• 43 = Network Segment, single-byte format, subtype 0x03 (Production Inhibit Time)
• 01 = (actually this is the structure for the variable-length format; simpler form uses bit 4 = 0)
• 0A = 10 milliseconds

A value of 0 means no production inhibit time. The default (when this segment is absent) is one-fourth the RPI. The RPI must be larger than the production inhibit time, otherwise Forward_Open fails with Extended Status 0x0111.

Safety Network Segment

Defined in Volume 5 (CIP Safety) but uses the standard Network Segment encoding. Carries the 6-byte Safety Network Number that uniquely identifies a CIP Safety subnet. For details on CIP Safety mechanics, see our CIP Safety Explained article.

Symbolic Segment

The Symbolic Segment contains a string symbol that the device must interpret. Per Volume 1 Section C-1.4.4:

Bit:    7   6   5   4   3   2   1   0
       └─Type─┘ └Symbol Size in Bytes┘
       └─011─┘

Symbol size 1-31: Length of ASCII symbol in bytes Symbol size 0: Extended string follows (Unicode, numeric, etc.)

Symbolic Segment examples

The Symbolic Segment is rarely used in standard EtherNet/IP I/O. It appears in older configurations where text-based addressing was preferred. Modern Logix systems use the ANSI Extended Symbol Segment (segment byte 91) for tag name addressing — covered below.

Data Segment

The Data Segment embeds data inline within a path. Used to deliver configuration data during connection establishment or to carry symbolic references. Per Volume 1 Section C-1.4.5:

Bit:    7   6   5   4   3   2   1   0
       └─Type─┘ └──Subtype──┘
       └─100─┘

Subtype values:

Simple Data Segment (0x80)

Embeds raw data values. The byte after 0x80 is the size in 16-bit words.

Example:

80 04 01 00 02 00 03 00 04 00
└┬┘└┬┘└────data — 4 words────┘
Type Sz=4

Decoded:

• 80 = Simple Data Segment
• 04 = 4 words of data follow
• 01 00 02 00 03 00 04 00 = words 1, 2, 3, 4 (little-endian)

When Forward_Open includes configuration data to send at connection establishment, that data is embedded as a Simple Data Segment within the Connection Path.

ANSI Extended Symbol Segment (0x91)

This is what Logix controllers use for tag-name addressing — the most-seen Data Segment subtype in real EtherNet/IP traffic. Per Volume 1 Section C-1.4.5.2:

91 06 73 74 61 72 74 31
└┬┘└┬┘└────── "start1" ──────┘
Type Sz=6 (chars)

Decoded:

• 91 = ANSI Extended Symbol Segment
• 06 = 6 characters in the symbol
• 73 74 61 72 74 31 = ASCII “start1”

If the symbol length is odd, a single zero pad byte follows to maintain word alignment:

91 07 73 74 61 72 74 65 72 00
└┬┘└┬┘└──── "starter" ────┘└┬┘
Type Sz=7                  pad

This is how a Logix MSG instruction reads a tag like Pump1.Speed from another controller — the tag name is encoded as an ANSI Extended Symbol Segment.

Padded vs Packed Paths

Per Volume 1 Section C-1.3, CIP supports two path formats:

When does padding matter?

For 8-bit logical addresses (most common), padded and packed are identical — both use 2 bytes per segment with no padding needed.

For 16-bit and 32-bit logical addresses, a pad byte appears in the Padded representation but not the Packed one:

16-bit Class ID, Packed:

21 05 00 24 02

16-bit Class ID, Padded:

21 00 05 00 24 02
   ▲
   pad byte

The pad byte (00) keeps the 16-bit Class ID value word-aligned within the path.

Which format is used where?

• Forward_Open Connection Paths use Padded EPATH by spec
• Request paths in CIP messages typically use Packed EPATH (called “Padded EPATH” in some sources due to inconsistent spec terminology)
• EDS file paths are typically Packed

When in doubt, check the spec for the specific service — Volume 1 documents whether each path field is Packed or Padded.

Building a path step by step

Engineers occasionally need to construct paths by hand — for custom CIP clients, EDS configuration, or troubleshooting. The process:

1. Identify the target: Class, Instance, Attribute (or Connection Point, Member ID)
2. Pick the right segment for each value:
   • Class ≤ 255 → 20 xx
   • Class > 255 → 21 xx xx (Packed) or 21 00 xx xx (Padded)
   • Instance ≤ 255 → 24 xx
   • Instance > 255 → 25 xx xx (Packed) or 25 00 xx xx (Padded)
   • Attribute ≤ 255 → 30 xx
3. Add routing segments if crossing networks:
   • Port Segment first (e.g., 01 02 for backplane to slot 2)
4. Add electronic keying if Forward_Open:
   • 10-byte Electronic Key Segment (34 04 ...)
5. Verify with Wireshark — capture and confirm Wireshark dissects it correctly

Example — reading Identity Object’s Product Name

Target: Class 0x01 (Identity), Instance 1, Attribute 7 (Product Name)

Path:

20 01 24 01 30 07
└─┬─┘ └─┬─┘ └─┬─┘
 Class  Inst  Attr
0x01     1     7

The complete Get_Attribute_Single request would be:

• Service: 0E (Get_Attribute_Single)
• Path Size: 03 (3 words = 6 bytes)
• Path: 20 01 24 01 30 07

Total: 8 bytes for the entire request.

Reading path segments in Wireshark

Wireshark’s CIP dissector decodes paths natively. Useful filters:

cip                                       # All CIP traffic
cip.epath                                 # Frames containing EPATHs
cip.class == 0x04                         # Anything addressed to Assembly Object class
cip.class == 0x06                         # Connection Manager
cip.epath.tag                             # Frames with ANSI Extended Symbol Segments (tag references)

When you click into a CIP packet, expand the path field. Wireshark shows each segment’s type and value:

Path Size: 8 words (16 bytes)
Path:
    Port Segment - Backplane, Slot 2
    Class Segment (0x20) - 0x04 (Assembly)
    Instance Segment (0x24) - 0x66
    Connection Point (0x2C) - 0x67
    Connection Point (0x2C) - 0x68

The hex bytes underneath the field show the raw encoding for verification. For broader Wireshark workflows, see our Wireshark for EtherNet/IP guide.

Common path-related errors

When path segments are wrong, the device returns specific status codes:

For complete error code coverage, see our CIP General Status Codes Reference.

Frequently asked questions

What is a CIP path segment?

A CIP path segment is an encoded unit of information that references a CIP entity — typically a Class, Instance, Attribute, or routing path. Path segments combine to form an EPATH (Encoded Path), the universal addressing format used in every CIP service request. The first byte of each segment encodes both the segment type (Port, Logical, Network, Symbolic, or Data) and its format. Defined in ODVA CIP Networks Library Volume 1, Appendix C.

What does 20 04 24 66 mean in CIP?

This is a CIP path that means “Class 0x04 (Assembly Object), Instance 0x66 (102).” Byte-by-byte: 20 is the Logical Segment for an 8-bit Class ID, 04 is the value 4 (Assembly Object class), 24 is the Logical Segment for an 8-bit Instance ID, and 66 is the value 102 (instance 102). This pattern appears in every Forward_Open Connection Path referencing an assembly instance.

What is the difference between Packed and Padded EPATH?

Both are CIP path encodings, but they differ in how they handle alignment. A Padded EPATH keeps each segment 16-bit word aligned by inserting pad bytes after segments with 16-bit or 32-bit logical values. A Packed EPATH concatenates segments directly with no pad bytes. For 8-bit logical addresses (most common), the two formats are identical. Forward_Open Connection Paths use Padded EPATH per spec; many other paths are Packed.

What is segment byte 0x20 in CIP?

0x20 is a Logical Segment Type byte indicating an 8-bit Class ID follows. The byte after 0x20 is the Class number. So 20 04 means “Class 0x04 (Assembly Object).” Other common Logical Segment Type bytes: 0x21 for 16-bit Class, 0x24 for 8-bit Instance, 0x30 for 8-bit Attribute, 0x2C for 8-bit Connection Point.

How is electronic keying encoded in a CIP path?

Electronic keying uses the Electronic Key Segment — a Special Logical Type encoded as segment byte 0x34. The segment contains Vendor ID, Device Type, Product Code, Major Revision (with Compatibility flag), and Minor Revision — all read from the device’s Identity Object. A typical Electronic Key Segment is 10 bytes total. Forward_Open Connection Paths include this segment so the target can validate it matches the actual hardware.

What does segment byte 0x91 mean in CIP?

0x91 is the ANSI Extended Symbol Segment — a Data Segment subtype used for tag-name addressing. The byte after 0x91 is the symbol length in characters, followed by the ASCII bytes of the symbol. So 91 06 73 74 61 72 74 31 decodes as the 6-character symbol “start1.” Logix MSG instructions use this segment type to address tags by name across controllers.

What is the Port Segment used for?

The Port Segment routes a CIP message across a subnet boundary — for example, from EtherNet/IP through a 1756-DNB scanner to a DeviceNet drop. Port Segment encodes the communication port to leave through (e.g., 1 = Backplane) and the link address of the next device. Multiple Port Segments can be chained to traverse multiple network hops.

How do I decode a CIP path in Wireshark?

Open the packet in Wireshark and expand the CIP layer. The Path field shows each segment decoded with its type and value (e.g., “Class Segment – Assembly Object (0x04)”). Below the decoded view, the raw hex bytes show the encoding. Common segment type bytes to recognize: 20 = 8-bit Class, 24 = 8-bit Instance, 2C = 8-bit Connection Point, 30 = 8-bit Attribute, 34 = Electronic Key, 80 = Simple Data, 91 = ANSI Extended Symbol.

What is General Status 0x04 in CIP path errors?

General Status 0x04 is “Path segment error” — the receiver couldn’t understand a segment type or format byte. Usually means the path is malformed: a truncated segment, an unknown segment type, or wrong path size. Different from General Status 0x05 (Path destination unknown), which means the path is syntactically valid but references something that doesn’t exist. For both codes, see our CIP General Status Codes Reference.

What is the Production Inhibit Time network segment?

A Network Segment subtype that specifies the minimum time (in milliseconds) between successive transmissions of connected data — preventing producers from flooding the network when data changes faster than the RPI. The default (when absent) is one-fourth the RPI. The RPI must be larger than the production inhibit time, otherwise Forward_Open fails with Extended Status 0x0111.

How are 16-bit Class IDs encoded?

Use the 16-bit Logical Format. The segment type byte is 0x21 (Logical Segment, Class ID, 16-bit format), followed by 2 bytes of Class ID value in little-endian order. So Class 0x0123 encodes as 21 23 01 in Packed format or 21 00 23 01 in Padded format (with a pad byte for word alignment). Most field devices use Class IDs ≤ 255, so 8-bit format (segment byte 0x20) is more common.