Wireshark · Wireshark-bugs: [Wireshark-bugs] [Bug 4028] New: CIP IOI path too short in response; ASSERT sometimes.

[bugzilla-daemon@xxxxxxxxxxxxx]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=4028

           Summary: CIP IOI path too short in response; ASSERT sometimes.
           Product: Wireshark
           Version: 1.3.x (Experimental)
          Platform: x86
        OS/Version: Windows XP
            Status: NEW
          Severity: Normal
          Priority: Medium
         Component: Wireshark
        AssignedTo: wireshark-bugs@xxxxxxxxxxxxx
        ReportedBy: jfielding@xxxxxxxxxxxxxxx


Created an attachment (id=3679)
 --> (https://bugs.wireshark.org/bugzilla/attachment.cgi?id=3679)
CIP explicit messages pcap

Build Information:
wireshark 1.3.0 (SVN Rev 29916 from /trunk)

Copyright 1998-2009 Gerald Combs <gerald@xxxxxxxxxxxxx> and contributors.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Compiled with GTK+ 2.16.5, with GLib 2.20.4, with WinPcap (version unknown),
with libz 1.2.3, without POSIX capabilities, with libpcre 7.0, with SMI 0.4.8,
with c-ares 1.6.0, with Lua 5.1, without Python, with GnuTLS 2.8.1, with Gcrypt
1.4.4, with MIT Kerberos, with GeoIP, with PortAudio V19-devel (built Sep 14
2009), with AirPcap.

Running on Windows XP Service Pack 2, build 2600, with WinPcap version 4.1
beta5
(packet.dll version 4.1.0.1452), based on libpcap version 1.0.0, GnuTLS 2.8.1,
Gcrypt 1.4.4, without AirPcap.

Built using Microsoft Visual C++ 9.0 build 30729
--
The CIP disector now matches requests and responses. Responses report the IOI
epath from requests. It's correct in requests, too short in responses. The
attachment contains 5 examples. (I extracted them from several real captures
and merged them, so times, IP addresses, TCP conversations are not consistent.)
The following table shows what happens. The Bytes column shows, for responses,
my estimate of path size actually used. Note that odd sizes are not possible.
The two odd size responses generate asserts:

Warn Dissector bug, protocol CIP, in packet 6: proto.c:1104: failed assertion
"DISSECTOR_ASSERT_NOT_REACHED"
Warn Dissector bug, protocol CIP, in packet 9: proto.c:1104: failed assertion
"DISSECTOR_ASSERT_NOT_REACHED"

        Frame   Bytes   Path
Req:    1       12      MSG_ZONE, Member: 0x00
Rsp:    2       10      MSG_ZONE
Req:    4       28      MSG_buffer, Member: 0x03, MSG_buffer, Member: 0x00
Rsp:    6       13      MSG_buffer,
Req:    8       24      MSG_Read, Member: 0x03, setting, Member: 0x00
Rsp:    9       11      MSG_Read,
Req:    11      6       Class: 0x66, Instance: 0x01
Rsp:    13      4       Class: 0x66
Req:    14      4       Connection Manager, Instance: 0x01
Rsp:    15      2       Connection Manager

I looked in packet-cip.c and think I can see at least part of the problem.
Function

dissect_epath( tvbuff_t *tvb, proto_item *epath_item, int offset, int
path_length, gboolean generate )

expects path_length in bytes, but the value from the packet is in words, so
there's lots of *2 and /2 in those parts of the code.

In this invocation

dissect_epath( tvbIOI, pi, 0, preq_info->IOILen, TRUE );

preq_info->IOILen is in words. This could explain most of the problem, but not
frames 6 and 9. As far as I can see, the half sizes (14 and 12 bytes
respectively) should give legal paths up to and including the first "Member:
0x03". The behaviour suggests the last byte (03) has been lost.

The code involved should be in case CI_LOGICAL_SEG_MBR_ID: inside the first if
(CI_LOGICAL_SEG_8_BIT).


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