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 4789] New: PER Bit string display misleading

Date: Tue, 25 May 2010 03:04:18 -0700 (PDT)
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=4789

           Summary: PER Bit string display misleading
           Product: Wireshark
           Version: SVN
          Platform: All
        OS/Version: Windows XP
            Status: NEW
          Severity: Normal
          Priority: Low
         Component: Wireshark
        AssignedTo: wireshark-bugs@xxxxxxxxxxxxx
        ReportedBy: Neil.Piercy@xxxxxxxxxxxx


Neil Piercy <Neil.Piercy@xxxxxxxxxxxx> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Attachment #4687|                            |review_for_checkin?
               Flag|                            |

Created an attachment (id=4687)
 --> (https://bugs.wireshark.org/bugzilla/attachment.cgi?id=4687)
patch to improve display

Build Information:
TShark 1.2.8ipa36

Copyright 1998-2010 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 (32-bit) with GLib 2.22.4, with WinPcap (version unknown), with libz
1.2.3, without POSIX capabilities, without libpcre, with SMI 0.4.8, with c-ares
1.7.0, with Lua 5.1, with GnuTLS 2.8.5, with Gcrypt 1.4.5, with MIT Kerberos,
with GeoIP.

Running on Windows XP Service Pack 3, build 2600, with WinPcap version 4.1.1
(packet.dll version 4.1.0.1753), based on libpcap version 1.0 branch 1_0_rel0b
(20091008), GnuTLS 2.8.5, Gcrypt 1.4.5.

Built using Microsoft Visual C++ 9.0 build 30729
--
See email thread
http://www.wireshark.org/lists/wireshark-dev/201003/msg00295.html

PER bit strings are displayed in hex (FT_BYTES), which means they need padding.
In 1.0.x. they were MSB-padded, but in 1.2.x they are LSB padded - neither is
right or wrong, but when (as is common in 3GPP usage) the bitstring is actually
used as a form of compression for integer values, LSB padding causes a lot of
confusion.

The ideal change would probably be to display in binar rather than hex, but the
proposed change is simpler and effective IMHO, as illustrated by the follwing
example:

1.0.x (MSB-padded)
  dl-HFN: 00000004 [bit length 25]

1.2.x/trunk (LSB-padded)
  dl-HFN: 00000200 [bit length 25]

1.2.x/trunk (LSB-padded - with explanation)
  dl-HFN: 00000200 [bit length 25, 7 LSB pad bits, decimal value 4]

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