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.