Wireshark-bugs: [Wireshark-bugs] [Bug 2173] New: Incorrect dissasembly of IPv6 packets with exte
Date: Mon, 7 Jan 2008 17:56:45 +0000 (GMT)
http://bugs.wireshark.org/bugzilla/show_bug.cgi?id=2173

           Summary: Incorrect dissasembly of IPv6 packets with extension
                    headers after the fragment header
           Product: Wireshark
           Version: SVN
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: Minor
          Priority: Low
         Component: Wireshark
        AssignedTo: wireshark-bugs@xxxxxxxxxxxxx
        ReportedBy: brayem@xxxxxxxx


Build Information:
wireshark 0.99.8 (SVN Rev 24020)

Compiled with GTK+ 2.12.0, with GLib 2.14.1, with libpcap 0.9.7, with libz
1.2.3.3, with libpcre 7.4, without SMI, with ADNS, without Lua, with GnuTLS
1.6.3, with Gcrypt 1.2.4, with MIT Kerberos, with PortAudio <= V18, without
AirPcap.

Running on Linux 2.6.22-14-generic, with libpcap version 0.9.7.

Built using gcc 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2).
--
When disassembling a packet in which additional IPv6 extension headers, such as
a second destination options header or an authentication header, those headers
should be treated as part of the fragmentable data, while the Next Header field
of the fragment header of each fragmented packet should still contain the code
for the first header in the fragmentable data.

Thus being the case, if there are additional IPv6 extension headers in each
fragmented packet, wireshark tries to disassemble the fragmented data in each
packet as if it contains that header, whereas it should only be present in the
first fragment.  For example, if the original packet had a destination options
header after the fragment header, wireshark will show a bogus destination
options header in each fragmented packet, followed by an invalid, truncated
data portion.

Below I'm attaching a very simple patch that gets around the basic
problem--with this patch packets like this are resassembled correctly. 
However, the reassembled packets are not dissected, and nothing useful is shown
about the upper-layer headers.  But this was my first look at wireshark's
source, so I don't have time *right now* to come up with a better solution.


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