| Bug ID |
8339
|
| Summary |
Add support for (USB) variable-length bitmasks
|
| Classification |
Unclassified
|
| Product |
Wireshark
|
| Version |
SVN
|
| Hardware |
All
|
| OS |
All
|
| Status |
UNCONFIRMED
|
| Severity |
Enhancement
|
| Priority |
Low
|
| Component |
Dissection engine (libwireshark)
|
| Assignee |
[email protected]
|
| Reporter |
[email protected]
|
| Attachment #10020 Flags |
review_for_checkin?
|
Created attachment 10020 [details]
Implementation
Build Information:
wireshark 1.9.0 (SVN Rev 47681 from /trunk)
Copyright 1998-2013 Gerald Combs <[email protected]> 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.12.10, with Pango 1.32.3,
with
GLib 2.34.2, with libpcap, with libz 1.2.7, with POSIX capabilities (Linux),
without libnl, with SMI 0.4.8, with c-ares 1.9.1, with Lua 5.1, without Python,
with GnuTLS 2.12.22, with Gcrypt 1.5.0, with MIT Kerberos, with GeoIP, with
PortAudio V19-devel (built Jul 21 2012 17:51:23), with AirPcap.
Running on Linux 3.7.6-201.fc18.x86_64, with locale en_US.UTF-8, with libpcap
version 1.3.0, with libz 1.2.7, GnuTLS 2.12.22, Gcrypt 1.5.0, without AirPcap.
Intel(R) Core(TM)2 Duo CPU T9900 @ 3.06GHz
Built using gcc 4.7.2 20121109 (Red Hat 4.7.2-8).
--
The USB protocol includes the concept of bitmask fields with an explicitly
specified length. Video Class structures that include paired "bmControl" and
"bControlSize" fields in the same data structure follow this pattern.
The primary intent of this is "forward compatibility," enabling an
interpreter coded for version M of a structure to comprehend fields in
version N of the structure, where N > M and bControlSize increases from version
M to version N.
The USB standards are silent on this point, but it may also be legal for
a device to transmit a shortened version of such a bitmask, with the
recipient to assume that standardized but untransmitted bits are all zero.
Wireshark's bitmask dissection API does not currently support these scenarios.
It is considered a dissector error for the internal function
proto_item_add_bitmask_tree() to be invoked on any sequence of bytes whose
length does not exactly match that of the fields involved. And, the public
bitmask API proto_tree_add_bitmask() does not allow callers to supply a length,
instead inferring it from the type of the header item.
This patch adds a new public API, proto_tree_add_bitmask_len(), identical to
proto_tree_add_bitmask() but using a caller-supplied length rather than an
inferred one. The underlying proto_item_add_bitmask_tree() code is modified
to display only fields for which all defined bits are available, and to
ignore bits that have no corresponding defined field ("forward compatibility"
cases).
This API assumes that variable-length bitmasks are extended at the MSb for
little-endian encoding, and at the LSb for big-endian encoding. Thus when
presented with more data than the dissector was coded to interpret,
MSbits will be ignored if the bitmask is little-endian and LSbits will be
ignored if the bitmask is big-endian. When presented with less data than
expected, MSfields will not be displayed for little-endian bitmasks and
LSfields will not be displayed for big-endian bitmasks.
One side effect of this patch is to legalize boolean display widths that are
not an integral number of bytes.
You are receiving this mail because:
- You are watching all bug changes.
