CIP I/O Packets Displayed Differently

asked 2021-05-20 18:53:41 +0000

JAKBaaW
1 ●1 ●1 ●2

updated 2021-05-20 18:59:19 +0000

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

edit retag flag offensive close merge delete

add a comment

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

Chuckc
3023 ●6 ●608 ●20

packet-enip.c

      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

edit flag offensive 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

CIP I/O Packets Displayed Differently

1 Answer

Comments

Your Answer

Question Tools

Stats

CIP I/O Packets Displayed Differently edit

1 Answer

Comments

Your Answer

Question Tools

Stats

CIP I/O Packets Displayed Differently