Bug ID |
10833
|
Summary |
Endianness seems incorrect for some ZigBee attribute decoding
|
Product |
Wireshark
|
Version |
1.99.x (Experimental)
|
Hardware |
x86
|
OS |
Windows 7
|
Status |
UNCONFIRMED
|
Severity |
Normal
|
Priority |
Low
|
Component |
Dissection engine (libwireshark)
|
Assignee |
[email protected]
|
Reporter |
[email protected]
|
Build Information:
Version 1.99.2-101-ga73b89b (v1.99.2rc0-101-ga73b89b from master)
Copyright 1998-2014 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 GTK+ 2.24.23, with Cairo 1.12.16, with Pango 1.36.8,
with
WinPcap (4_1_3), with libz 1.2.5, with GLib 2.42.0, with SMI 0.4.8, with c-ares
1.9.1, with Lua 5.2, with GnuTLS 3.2.15, with Gcrypt 1.6.2, with MIT Kerberos,
with GeoIP, with PortAudio V19-devel (built Dec 18 2014), with AirPcap.
Running on 64-bit Windows 7 Service Pack 1, build 7601, with WinPcap version
4.1.3 (packet.dll version 4.1.0.2980), based on libpcap version 1.0 branch
1_0_rel0b (20091008), with GnuTLS 3.2.15, with Gcrypt 1.6.2, without AirPcap.
Intel(R) Xeon(R) CPU W3530 @ 2.80GHz (with SSE4.2), with 6141MB of
physical memory.
Built using Microsoft Visual C++ 12.0 build 30501
--
When I view a dissection of a ZigBee Read Attribute Response with a 16-bit
Bitmap type, the bytes appear to be swapped from what I would expect.
Looking at line 1584 of packet-zbee-zcl.c, I can see the encoding type is set
to ENC_NA, where I might have expected ENC_LITTLE_ENDIAN - unfortunately I am
not in a position to build code to test this.
If this is the case, then the other xx_BIT_BITMAP types are affected, and maybe
also the xx_BIT_DATA (although I forget which way this should be encoded).
You are receiving this mail because:
- You are watching all bug changes.