Wireshark · Wireshark-bugs: [Wireshark-bugs] [Bug 2366] New: X25 reassembly fragment table and dissected proto presented for all

[bugzilla-daemon@xxxxxxxxxxxxx]

http://bugs.wireshark.org/bugzilla/show_bug.cgi?id=2366

           Summary: X25 reassembly fragment table and dissected proto
                    presented for all X25 packets
           Product: Wireshark
           Version: SVN
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: Normal
          Priority: Low
         Component: Wireshark
        AssignedTo: wireshark-bugs@xxxxxxxxxxxxx
        ReportedBy: gerhard.nospam@xxxxxxxxx



Gerhard Olsson <gerhard.nospam@xxxxxxxxx> changed:

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


Created an attachment (id=1565)
 --> (http://bugs.wireshark.org/bugzilla/attachment.cgi?id=1565)
Use m_bit_set to control if reassembly table should be shown

Build Information:
svn: 24667

TShark 0.99.9 (SVN Rev unknown)

Copyright 1998-2008 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 GLib 1.2.10, with libpcap 0.9.8, with libz 1.2.3, without POSIX
capabilities, with libpcre 5.0, with SMI 0.4.5, without ADNS, without Lua,
without GnuTLS, without Gcrypt, without Kerberos.

Running on SunOS 5.10, with libpcap version 0.9.8.

Built using gcc 3.4.2.

--
When dissecting x25 where x25 reassembly is activated (X25 preferences), the
defragment table and the follow up dissect data is normally displayed in all
X25 packets.
This is confusing when reading:
  Several reassembly tables created
  Subsequent dissected protocols are presented several times in the list (This
is can be seen by enabling Asume QLLC/SNA in X25 preferences)

The reason seems to be that fragment_add_seq_next() always return a fd_head.
The reassembly code seems to assume that there is only one x25 packet in each
pinfo structure as well, which is not the case.
I cannot find the problem in reassemble.c (and this affects other formats where
this is the expected behaviour?) and therefore supply a a patch for X25 only.

A test case where the ethernet frame consists of two X25 packets 
http://bugs.wireshark.org/bugzilla/attachment.cgi?id=1551
(from http://bugs.wireshark.org/bugzilla/show_bug.cgi?id=2347)

A separate testcase where the x25 packet is separated is also included


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