Wireshark-bugs: [Wireshark-bugs] [Bug 4265] New: 6LoWPAN may try to read UDP checksum when it is
Date Index · Thread Index · Other Months · All Mailing Lists
Date Prev · Date Next · Thread Prev · Thread Next
From: bugzilla-daemon@xxxxxxxxxxxxx
Date: Wed, 25 Nov 2009 09:08:58 -0800 (PST)
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=4265

           Summary: 6LoWPAN may try to read UDP checksum when it is not
                    there
           Product: Wireshark
           Version: 1.3.x (Experimental)
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: Normal
          Priority: Medium
         Component: Wireshark
        AssignedTo: wireshark-bugs@xxxxxxxxxxxxx
        ReportedBy: beth.tridium@xxxxxxxxx
                CC: beth.tridium@xxxxxxxxx


Created an attachment (id=3996)
 --> (https://bugs.wireshark.org/bugzilla/attachment.cgi?id=3996)
Patch to fix UDP length bug in 6lowpan dissector

Build Information:
Version 1.3.2-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.6, with GLib 2.22.2, 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.5, with Gcrypt
1.4.4, with MIT Kerberos, with GeoIP, with PortAudio V19-devel (built Nov 24
2009), with AirPcap, with new_packet_list.

Running on Windows XP Service Pack 3, 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.5,
Gcrypt 1.4.4, without AirPcap.

Built using Microsoft Visual C++ 9.0 build 21022


--

When a 6lowpan message has a compressed UDP length (i.e. the length must be
calculated, not read from the headers), the 6lowpan dissector correctly reports
that the UDP length is compressed, but it may try to read the length from the
headers anyway.  

In most cases that means it reads the checksum bytes as the UDP length.  Not
only does this result in a bad UDP length, it also mangles the interpretation
of the rest of the frame.

It looks like a simple typo in the dissector code, where the bit is checked
correctly in one location and not in the other.  I am attaching a patch that
fixes the problem.


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