Huge thanks to our Platinum Members Endace and LiveAction,
and our Silver Member Veeam, for supporting the Wireshark Foundation and project.

Wireshark-bugs: [Wireshark-bugs] [Bug 3103] New: CIP and ENIP dissector enhancements

Date: Tue, 9 Dec 2008 04:26:28 -0800 (PST)
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=3103

           Summary: CIP and ENIP dissector enhancements
           Product: Wireshark
           Version: unspecified
          Platform: PC
        OS/Version: Windows XP
            Status: NEW
          Severity: Enhancement
          Priority: Medium
         Component: Wireshark
        AssignedTo: wireshark-bugs@xxxxxxxxxxxxx
        ReportedBy: jow@xxxxxx



Joakim Wiberg <jow@xxxxxx> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Attachment #2541|                            |review_for_checkin?
               Flag|                            |


Created an attachment (id=2541)
 --> (https://bugs.wireshark.org/bugzilla/attachment.cgi?id=2541)
CIP and ENIP dissector patch

Build Information:
Paste the COMPLETE build information from "Help->About Wireshark", "wireshark
-v", or "tshark -v".
--
A while ago Jan Bartels contacted me with improvements that he made to the CIP
and ENIP dissectors. The changes he made was against 0.99.6 so I have made them
up to date with the latest SVN source. 

The patch is tested with fuzz-test.sh.

>From Jan Bartels:

packet-enip tries to map the request-response-pairs based on either the
sender's context if unconnected or the sequence-numbers for connected
CIP-messages. It sets up Wireshark-connections to track the
CIP-connection-identifiers. This whole part is a bit heuristic. If you have
better ideas to manage the mapping process, feel free to implement them. The
dissector attaches a pointer to a structure containing time-information and the
packet numbers of the request and the response. This structure is allocated for
every request. Dissecting a response, packet-enip searches for the
corresponding request and attaches the found request-structure to the response,
too. This structure is evaluated later by the CIP-dissector storing IOI-related
infos. I've tested it with explicit messaging only. It may not work with
Multicast-CIP-traffic as there's just one field to store the packet number of
the response. This should be an array then.

The enip-dissector calculates and displays the response-time for any request.
It links the packets per hyperlink in the tree-window. This feature is very
helpful when using a display filter to search missing response-packets (filter
expressions enip.response_in, enip.response_to and
enip.time) or if you just want to jump between the matching request and
response packets.

packet-cip allocates an own structure holding information like the IOI and the
class dissector for every request. This information is stored in the structure
already allocated and attached by packet-enip. Response packets just use the
stored dissector. By this means the response can be evaluated and displayed
correctly without having an IOI in the response-packet. Every CIP-object/class
has an own dissector in packet-cip or external plugins (register them for
"cip.class.iface"). Our vendor-specific CIP-dissectors are implemented
separately as a plugin registering for the appropriate classes. The
Message-Router-dissector allocates some additional private structures for the
embedded services to allow correct dissecting of the response packet.


-- 
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.