Wireshark · Wireshark-bugs: [Wireshark-bugs] [Bug 3868] New: packet-dtn.c dissector assumes timestamp seq number is 32bit

[bugzilla-daemon@xxxxxxxxxxxxx]

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

           Summary: packet-dtn.c dissector assumes timestamp seq number  is
                    32bit
           Product: Wireshark
           Version: 1.3.x (Experimental)
          Platform: x86
        OS/Version: Ubuntu
            Status: NEW
          Severity: Major
          Priority: Low
         Component: Extras
        AssignedTo: wireshark-bugs@xxxxxxxxxxxxx
        ReportedBy: lnevers@xxxxxxx
                CC: lnevers@xxxxxxx


Build Information:
Using:

TShark 1.1.3

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 GLib 2.20.0, 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 GnuTLS, without Gcrypt, without Kerberos, without GeoIP.
NOTE: this build doesn't support the "matches" operator for Wireshark filter
syntax.

Running on Linux 2.6.27-7-server, with libpcap version 1.0.0.

Built using gcc 4.3.2.

Description:

The following captures show a captured DTN bundle:

    Bundle Protocol
    Primary Bundle Header
        Bundle Version: 6
        Bundle Processing Control Flags: 0x8110
            General Flags
                .... ...0 = Bundle is a Fragment: False
                .... ..0. = Administrative Record: False
                .... .0.. = Do Not Fragment Bundle: False
                .... 0... = Request Custody Transfer: False
                ...1 .... = Destination is Singleton: True
                ..0. .... = Request Acknowledgment by Application: False
            Class of Service Flags
                01 -- Priority = Normal
            Status Report Request Flags
                .... ...0 = Request Reception Report: False
                .... ..0. = Request Report of Custody Acceptance: False
                .... .0.. = Request Report of Bundle Forwarding: False
                .... 0... = Request Report of Bundle Delivery: False
                ...0 .... = Request Report of Bundle Deletion: False
        Bundle Header Length: 62
        Destination Scheme Offset: 0
        Destination SSP Offset: 4
        Source Scheme Offset: 0
        Source SSP Offset: 20
        Report Scheme Offset: 0
        Report SSP Offset: 20
        Custodian Scheme Offset: 0
        Custodian SSP Offset: 36
        Timestamp: 0x120afcc5 [Tue Aug  4 10:05:57 2009]  
        Timestamp Sequence Number: 4             <<<<****issue**** >>>>>>>   
        Lifetime: 3600
        Dictionary Length: 41
        Dictionary
            Destination Scheme: dtn
            Destination: //node170/recv
            Source Scheme: dtn
            Source: //node169/send
            Report Scheme: dtn
            Report: //node169/send
            Custodian Scheme: dtn
            Custodian: none
    Payload Header
        Header Type: 1
        Block Processing Control Flags: 0x08
            .... ...0 = Replicate Block in Every Fragment: False
            .... ..0. = Transmit Status if Block Can't be Processeed: False
            .... .0.. = Delete Bundle if Block Can't be Processeed: False
            .... 1... = Last Block: True
            ...0 .... = Discard Block If Can't Process: False
            ..0. .... = Block Was Forwarded Without Processing: False
            .0.. .... = Block Contains an EID-reference Field: False
        Payload Length: 4

Comparing the time-stamp sequence number on bundles generated by our BPA,
which are a 64-bit number. The time-stamp sequence number generated is the
(hex) value 0x600000004,but It looks like the current DTN dissector is 
expecting the sequence number to be no larger than 32 bits, this is a bug. 
--


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