https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=7933
Summary: Add ability to reverse FT_BYTES for display
Product: Wireshark
Version: SVN
Platform: x86
OS/Version: All
Status: NEW
Severity: Enhancement
Priority: Low
Component: Wireshark
AssignedTo: bugzilla-admin@xxxxxxxxxxxxx
ReportedBy: steve@xxxxxxxxxxxxxxx
Steve Magnani <steve@xxxxxxxxxxxxxxx> changed:
What |Removed |Added
----------------------------------------------------------------------------
Attachment #9445| |review_for_checkin?
Flags| |
Created attachment 9445
--> https://bugs.wireshark.org/bugzilla/attachment.cgi?id=9445
Proposed patch
Build Information:
wireshark 1.9.0 (SVN Rev 45826 from /trunk)
Copyright 1998-2012 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 (64-bit) with GTK+ 2.24.13, with Cairo 1.10.2, with Pango 1.30.0, with
GLib 2.32.4, with libpcap, with libz 1.2.5, with POSIX capabilities (Linux),
without libnl, without SMI, without c-ares, without ADNS, without Lua, without
Python, with GnuTLS 2.12.17, with Gcrypt 1.5.0, with MIT Kerberos, without
GeoIP, without PortAudio, with AirPcap.
Running on Linux 3.6.2-4.fc17.x86_64, with locale en_US.UTF-8, with libpcap
version 1.2.1, with libz 1.2.5, GnuTLS 2.12.17, Gcrypt 1.5.0, without AirPcap.
Built using gcc 4.7.2 20120921 (Red Hat 4.7.2-2).
--
Currently, the encoding argument of proto_tree_add_item() is ignored for
FT_BYTES fields. Such fields are always displayed big-endian.
Some USB classes (i.e., Video) define bitmap ("bmXXX") fields whose length is
specified within a message (a kind of FT_UINT_BYTES). These can be dissected as
sub-trees of booleans rooted on a FT_BYTES item. USB mandates little-endian
byte ordering; with the current FT_BYTES implementation, the bitmap field value
(subtree root) displays in big-endian ordering. This is confusing since the
subtree indicates parsing of the bitmap in little-endian ordering.
For example:
bControlSize: 2
bmControl: 5b17
.... .... .... .... .... ...1 = Brightness: YES
.... .... .... .... .... ..1. = Contrast: YES
.... .... .... .... .... .0.. = Hue: NO
.... .... .... .... .... 1... = Saturation: YES
.... .... .... .... ...1 .... = Sharpness: YES
.... .... .... .... ..0. .... = Gamma: NO
.... .... .... .... .1.. .... = White Balance Temperature: YES
.... .... .... .... 0... .... = White Balance Component: NO
.... .... .... ...1 .... .... = Backlight Compensation: YES
.... .... .... ..1. .... .... = Gain: YES
.... .... .... .1.. .... .... = Power Line Frequency: YES
.... .... .... 0... .... .... = Hue, Auto: NO
.... .... ...1 .... .... .... = White Balance Temperature, Auto: YES
.... .... ..0. .... .... .... = White Balance Component, Auto: NO
.... .... .0.. .... .... .... = Digital Multiplier: NO
.... .... 0... .... .... .... = Digital Multiplier Limit: NO
.... ...0 .... .... .... .... = Analog Video Standard: NO
.... ..0. .... .... .... .... = Analog Video Lock Status: NO
FT_BYTES is used in many dissectors and the current big-endian behavior is
assumed. So it seems prudent to limit the scope of little-endian support to
limit breakage of existing functionality. Also, a generic solution may not be
achievable for FT_UINT_BYTES, where it is possible that the length field has
one ordering but the data field has a different ordering.
Attached is a patch to add endian support only for FT_BYTES, only via
proto_tree_add_item(), and only when ENC_LITTLE_ENDIAN is specified. This
should cover the USB case with minimal disruption to existing functionality.
--
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.
