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 4109] New: Decoding [Status Records] Timestamp Sequence Fi

Date: Fri, 9 Oct 2009 11:35:24 -0700 (PDT)
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=4109

           Summary: Decoding [Status Records] Timestamp Sequence Field in
                    Bundle Protocol fails if over 32 bits
           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: jzinky@xxxxxxx
                CC: donc@xxxxxxxxx
        Depends on: 3914


Created an attachment (id=3764)
 --> (https://bugs.wireshark.org/bugzilla/attachment.cgi?id=3764)
DTN Bundle Protocol with greater than 32 bits Time Stamp Sequence Numbers

Build Information:
Version 1.3.1 (SVN Rev 30433 from /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.0, with GLib 2.20.0, with libpcap 0.9.8, with libz
1.2.3.3, without POSIX capabilities, without libpcre, without SMI, without
c-ares, without ADNS, without Lua, without Python, without GnuTLS, without
Gcrypt, without Kerberos, without GeoIP, without PortAudio, without AirPcap,
with new_packet_list.
NOTE: this build doesn't support the "matches" operator for Wireshark filter
syntax.

Running on Linux 2.6.27-7-generic, with libpcap version 0.9.8.

Built using gcc 4.3.2.

Wireshark is Open Source Software released under the GNU General Public
License.

Check the man page and http://www.wireshark.org for more information.
--
Bug 3914 did not get all the fields that use BundleID:Timestamp:Sequence Number

A new DTN BPA has Timestamp sequence numbers which can be 64 bits or two int 
   [bpa incarnation __ seq number]:

The fix would be to make all  Timestamp Sequence Number a long (64 bit).
Also, the long could be further parsed as two subfields:
  [high order int-incarnation number __ low order int -sequence number]

Included is a wireshark trace, that has a two pings between hosts pacer7 and
pacer23.
1) Bundles sent by pacer7 have an incarnation number of 196609
 The bundle Timestamp sequence number is bigger than 32 bits
THIS PARSES CORRECTlY (thanks to fix 3914)

2) Administrative Status record bundles are also being returned
 The status record Bundle ID: Bundle Creation Timestamp is bigger than 32 bits
(Parse Error)

*** Work around
If the current incarnation number is just a few bits, it fits within the
high-order bit padding for the 
SDNV encoded int (32 bits) for the Timestamp sequence number.

SDNV takes 5 bytes to encode an unsigned int with the top bit set.
5*7 is 35, so there are 3 bits of padding which are ignored by wireshark, but
can have a valid bpa incarnation number stored in these bits, up to incarnation
number of 7.

So reset your BPA incarnation number

***** Application output for TRACE
The test application output shows the bundles sent and received by DTN
application.
(The of the status record bundles from pacer7 do not go over the wire)
*
Connected to BPA pacer7/128.89.80.149 port=5010 Local
eid=dtn://pacer7/sendingPing/11188 Remote eid=dtn://pacer23/ping connectTime=4
buildIdTime=2
Registered local eid dtn://pacer7/sendingPing/11188 Registration ID =1
   22 Sent Bundle: 1 expire=1 payload size=1000 Bundle:
dtn://pacer7/sendingPing/11188(308413817:196609_1)[0..999]
   28 Status[.CF...] dtn://pacer7/admin Reason: NO_ADDTL_INFO
Accepted-Custody=0 Forward=0
   30 Status[....X.] dtn://pacer7/admin Reason: NO_ADDTL_INFO Deleted=0
   33 Received 1000 bytes from dtn://pacer23/admin count=1 time=32
   34 Status[RC.D..] dtn://pacer23/admin Reason: NO_ADDTL_INFO Received=0
Accepted-Custody=0 Delivered=0
   35 Status[....X.] dtn://pacer23/admin Reason: NO_ADDTL_INFO Deleted=0

    2 Sent Bundle: 2 expire=1 payload size=1000 Bundle:
dtn://pacer7/sendingPing/11188(308413827:196609_4)[0..999]
    6 Status[.CF...] dtn://pacer7/admin Reason: NO_ADDTL_INFO
Accepted-Custody=0 Forward=0
    9 Status[....X.] dtn://pacer7/admin Reason: NO_ADDTL_INFO Deleted=0
   11 Received 1000 bytes from dtn://pacer23/admin count=2 time=11
   11 Status[RC.D..] dtn://pacer23/admin Reason: NO_ADDTL_INFO Received=0
Accepted-Custody=0 Delivered=0
   12 Status[....X.] dtn://pacer23/admin Reason: NO_ADDTL_INFO Deleted=0


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