Ask Your Question

Dissection of CIP Message Router Response

asked 2019-09-09 14:56:39 +0000

CiderGlider gravatar image

updated 2019-09-09 15:35:34 +0000

The dissection of a CIP Message Router Response packet contains some spurious information.

Under the heading "Common Industrial Protocol", after the Additional Status Size field, there appear a Request Path Size and a Request Path. These don't correspond to any bytes in this packet. The Request Path Size and Request Path are present in the previous packet, a Message Router Request, so this spurious information seems to be a hangover from that packet.

Link to capture file: link text

Ethernet II, Src: Rockwell_98:a9:83 (5c:88:16:98:a9:83), Dst: LcfcHefe_91:c1:f9 (54:e1:ad:91:c1:f9)
Internet Protocol Version 4, Src:, Dst:
Transmission Control Protocol, Src Port: 44818, Dst Port: 6779, Seq: 267, Ack: 285, Len: 70
EtherNet/IP (Industrial Protocol), Session: 0xB176B060, Send RR Data
    Encapsulation Header
        Command: Send RR Data (0x006f)
        Length: 46
        Session Handle: 0xb176b060
        Status: Success (0x00000000)
        Sender Context: 19000000d8917902
        Options: 0x00000000
    Command Specific Data
        Interface Handle: CIP (0x00000000)
        Timeout: 5
        Item Count: 2
        [Request In: 165]
        [Time: 0.001961000 seconds]
Common Industrial Protocol
    Service: Unknown Service (0x54) (Response)
        1... .... = Request/Response: Response (0x1)
        .101 0100 = Service: Unknown (0x54)
    Status: Success: 
        General Status: Success (0x00)
        Additional Status Size: 0 words
    [Request Path Size: 2 words]
    [Request Path: Connection Manager, Instance: 0x01]
        [Path Segment: 0x20 (8-Bit Class Segment)]
        [Path Segment: 0x24 (8-Bit Instance Segment)]
CIP Connection Manager
    Service: Forward Open (Response)
        1... .... = Request/Response: Response (0x1)
        .101 0100 = Service: Forward Open (0x54)
    Command Specific Data
        O->T Network Connection ID: 0x0943c0b7
        T->O Network Connection ID: 0x80fe0001
        Connection Serial Number: 0x0002
        Originator Vendor ID: Rockwell Software, Inc. (0x004d)
        Originator Serial Number: 0x26fe450d
        O->T API: 7500.000ms
        T->O API: 7500.000ms
        Application Reply Size: 0 words
        Reserved: 0x00
        [CIP Connection Index: 0]
edit retag flag offensive close merge delete


Wireshark version?

Can you share the capture file?

grahamb gravatar imagegrahamb ( 2019-09-09 15:01:11 +0000 )edit

The version is 3.0.3.

How do I go about sharing the capture file? I can't see an option to attach to a posting.

CiderGlider gravatar imageCiderGlider ( 2019-09-09 15:10:00 +0000 )edit

Post the file on a public file sharing site, e.g. Google Drive, DropBox etc. and then post a link to the file back here by editing your question.

grahamb gravatar imagegrahamb ( 2019-09-09 15:31:04 +0000 )edit

The link you shared doesn't seem to be publicly viewable.

grahamb gravatar imagegrahamb ( 2019-09-09 15:41:53 +0000 )edit

Sorry, I've changed it to be public now.

CiderGlider gravatar imageCiderGlider ( 2019-09-09 15:47:32 +0000 )edit

1 Answer

Sort by ยป oldest newest most voted

answered 2019-09-09 15:59:41 +0000

grahamb gravatar image

updated 2019-10-01 13:39:17 +0000

You'll note that the items you reference have square brackets ([]) around them, this means they are synthesised by the dissector from information elsewhere.

In this case the information appears to be from the clients request to the server in the the previous frame.

This extra synthesised information was deemed useful by the dissector writer and is fairly normal for Wireshark dissectors. For instance it allows a filter to show both requests and responses that reference the same path segments.

edit flag offensive delete link more


Thanks for explaining that. Every day's a school day!

CiderGlider gravatar imageCiderGlider ( 2019-09-10 07:40:35 +0000 )edit

But could you provide me logic behind finding of exact request (packet) no. associated with each response packet while parsing ?

Currently I am mapping response & request of CIP packets, by comparing response's seq. no with request's ack no. number. But this is not always true.

How wireshark has implemented this ?

vikrant gravatar imagevikrant ( 2019-10-01 13:26:54 +0000 )edit

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

1 follower


Asked: 2019-09-09 14:56:39 +0000

Seen: 2,360 times

Last updated: Oct 01 '19