Build Information:
Wireshark 2.3.0 (v2.3.0rc0-1524-g36b4830)
Copyright 1998-2016 Gerald Combs <[email protected]> and contributors.
License GPLv2+: GNU GPL version 2 or later
<http://www.gnu.org/licenses/old-licenses/gpl-2.0.html>
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 Qt 5.6.1, with libpcap, with POSIX capabilities (Linux),
with libnl 3, with GLib 2.50.0, with zlib 1.2.8, with SMI 0.4.8, with c-ares
1.12.0, with Lua 5.2.4, with GnuTLS 3.5.4, with Gcrypt 1.7.3-beta, with MIT
Kerberos, with GeoIP, with nghttp2 1.15.0, without LZ4, without Snappy, with
QtMultimedia, without AirPcap.
Running on Linux 4.7.0-1-amd64, with Intel(R) Core(TM) i7-2600 CPU @
3.40GHz (with SSE4.2), with 15980 MB of physical memory, with locale
en_US.UTF-8, with libpcap version 1.7.4, with GnuTLS 3.5.4, with Gcrypt
1.7.3-beta, with zlib 1.2.8.
Built using clang 4.2.1 Compatible Clang 3.9.0 (tags/RELEASE_390/final).
--
On latest master, when calling proto_tree_add_item_ret_string() with the length
field set to -1 (e.g. with a STRINGZ field type), the string is correctly
extracted and returned, but the length of the resulting field is wrong.
Fortunately, there seems to be only one existing dissector that is affected by
this, because it's the only one making such a call: packet-wbxml.c (on the
hf_wbxml_string_table_item_string). However it bit me in
https://code.wireshark.org/review/18901/.
STEPS TO REPRODUCE:
In Wireshark, open the WAP_WBXML_Provisioning_Push.pcap sample capture from
https://wiki.wireshark.org/SampleCaptures. In the protocol tree, expand "WAP
Binary XML", "String table", "0" and then select "String: NAP1".
EXPECTED RESULT:
When selecting the field in Wireshark, the corresponding capture data in the
"Packet Bytes" pane should be highlighted.
ACTUAL RESULT:
Nothing is highlighted (i.e. the field length is zero).
ADDITIONAL INFORMATION:
I suspect this is a trivial bug in the implementation of
proto_tree_add_item_ret_string_and_length(), which uses "length" (which in that
case would be -1) instead of "*lenretval" (which contains the actual length)
when calling new_field_info().
You are receiving this mail because:
- You are watching all bug changes.