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 5047] New: 6lowpan dissector fails RFC 4944 compliance

Date: Fri, 23 Jul 2010 00:30:40 -0700 (PDT)
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=5047

           Summary: 6lowpan dissector fails RFC 4944 compliance
           Product: Wireshark
           Version: 1.4.0
          Platform: Other
        OS/Version: All
            Status: NEW
          Severity: Major
          Priority: Low
         Component: Wireshark
        AssignedTo: wireshark-bugs@xxxxxxxxxxxxx
        ReportedBy: john.sucaet@xxxxxxxxx


Build Information:
Version 1.4.0rc1

Compiled with GTK+ 2.20.1, (32-bit) with GLib 2.24.1, with libpcap 1.0.0, with
libz 1.2.3.3, without POSIX capabilities, without libpcre, without SMI, without
c-ares, without ADNS, without Lua, without Python, with GnuTLS 2.8.5, with
Gcrypt 1.4.4, without Kerberos, without GeoIP, without PortAudio, without
AirPcap.

Running on Linux 2.6.32-23-generic, with libpcap version 1.0.0, with libz
1.2.3.3, GnuTLS 2.8.5, Gcrypt 1.4.4.

Built using gcc 4.4.3.

--
packet-6lowpan.c dissects the non-compressed ipv6 fields in an order different
from the one specified in RFC 4944 §10.3.1


Excerpt from the RFC 4944:
"The non-compressed IPv6 field that MUST be always present is the Hop
   Limit (8 bits).  This field MUST always follow the encoding fields
   (e.g., "HC1 encoding" as shown in Figure 9), perhaps including other
   future encoding fields).  Other non-compressed fields MUST follow the
   Hop Limit as implied by the "HC1 encoding" in the exact same order as
   shown above (Section 10.1): source address prefix (64 bits) and/or
   interface identifier (64 bits), destination address prefix (64 bits)
   and/or interface identifier (64 bits), Traffic Class (8 bits), Flow
   Label (20 bits) and Next Header (8 bits).  The actual next header
   (e.g., UDP, TCP, ICMP, etc) follows the non-compressed fields.
"

The order in packet-6lowpan.c is as follows (extracted from source):
- traffic class
- flow label
- next header
- hop limit
- source address
- destination address

The order specified in RFC 4944:
- hop limit
- source address
- destination address
- traffic class
- flow label
- next header

(A capture file is not provided as I am using the wireshark dissector to test
my own implementation of 6lowpan)

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