First time here? Check out the FAQ!
THIS IS A TEST INSTANCE. Feel free to ask and answer questions, but take care to avoid triggering too many notifications.
0

Dissection of CIP Message Router Response

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: 10.141.114.211, Dst: 10.141.114.93
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]
CiderGlider's avatar
1
CiderGlider
asked 2019-09-09 14:56:39 +0000, updated 2019-09-09 15:35:34 +0000
edit flag offensive 0 remove flag close merge delete

Comments

Wireshark version?

Can you share the capture file?

grahamb's avatar grahamb (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's avatar CiderGlider (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's avatar grahamb (2019-09-09 15:31:04 +0000) edit

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

grahamb's avatar grahamb (2019-09-09 15:41:53 +0000) edit

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

CiderGlider's avatar CiderGlider (2019-09-09 15:47:32 +0000) edit
add a comment see more comments

1 Answer

0

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.

grahamb's avatar
23.8k
grahamb
answered 2019-09-09 15:59:41 +0000, updated 2019-10-01 13:39:17 +0000
edit flag offensive 0 remove flag delete link

Comments

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

CiderGlider's avatar CiderGlider (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 ?

https://ask.wireshark.org/question/11...

vikrant's avatar vikrant (2019-10-01 13:26:54 +0000) edit
add a comment see more comments

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account. This space is reserved only for answers. If you would like to engage in a discussion, please instead post a comment under the question or an answer that you would like to discuss.

Add Answer