CIP I/O Packets Displayed Differently

retag add tags

I'm reviewing a capture I was sent recently. I have packets in the same capture of the same protocol (CIP I/O) which are displaying differently. One shows details and separates out the 32-bit header and one does not.

I think maybe they are being dissected differently? How do I confirm? Then, why are packets of the same protocol dissecting differently?

I'm unable to upload the photo so please see the two examples below:

(with details)

Common Industrial Protocol, I/O

CIP Sequence Count: 2
32-bit Header: 0x00000021, Run/Idle: Run
    .... .... .... .... .... .... .... 00.. = ROO: 0x0
    .... .... .... .... .... .... .... ..0. = COO: 0x0
    .... .... .... .... .... .... .... ...1 = Run/Idle: Run (0x1)
Data: 0000

(without details)

Common Industrial Protocol, I/O

CIP Sequence Count: 0
Data: 210000000000

JAKBaaW

asked 2021-05-20 18:53:41 +0000, updated 2021-05-20 18:59:19 +0000

edit flag offensive 0 remove flag close merge delete

Comments

add a comment see more comments

1 Answer

Sort by

      if ((tvb_reported_length_remaining(tvb, offset) >= 4) &&
         (((io_data_input->connid_type == ECIDT_O2T) && enip_OTrun_idle) ||
         ((io_data_input->connid_type == ECIDT_T2O) && enip_TOrun_idle)))
      {
         dissect_cip_run_idle(tvb, offset, io_tree);
         offset += 4;
      }

There are two preferences that affect this and the default is to only do one direction:

static gboolean enip_OTrun_idle = TRUE;
static gboolean enip_TOrun_idle = FALSE;

Check the protocol preferences to see if only one is checked.

image description

Chuckc

answered 2021-05-20 19:58:29 +0000

edit flag offensive 0 remove flag delete link

Comments

It does look like both are checked. I failed to mention, but both packets are T->O.

JAKBaaW (2021-05-21 11:29:01 +0000) edit

Can you provide a packet capture?

Chuckc (2021-05-21 14:19:07 +0000) edit

I don't have enough "points" to upload a file to the forum, so I apologize if this violates forum policy. Capture is linked below. See packet numbers 47 (no details) and 51 (with details)

https://drive.google.com/file/d/1SCJ6...

JAKBaaW (2021-05-21 14:34:14 +0000) edit

Possibly a bug. Raise an issue at the Wireshark Gitlab site.

There has been a good bit of work on conversations (Issue #6617 and many more commits since).

I haven't traced it in the debugger yet but the code in packet-enip.c checks for a conversation:

static cip_conn_info_t*
enip_get_io_connid(packet_info *pinfo, guint32 connid, enum enip_connid_type* pconnid_type)
{
SNIP

   /*
    * Do we have a conversation for this connection?
    */
   conversation = find_conversation(pinfo->num,
            &pinfo->src, &pinfo->dst,
            conversation_pt_to_endpoint_type(pinfo->ptype),
            pinfo->destport, 0, NO_PORT_B);

   if (conversation == NULL)
      return NULL;

If you right-click frame 47 in the packet list, go to Conversation Filter and see that CIP Connection is greyed out.

Chuckc (2021-05-21 17:04:37 +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

CIP I/O Packets Displayed Differently edit

Comments

1 Answer

Comments