Wireshark-bugs: [Wireshark-bugs] [Bug 12984] New: IEEE802.15.4 frames erroneously handed over to
| Bug ID |
12984
|
| Summary |
IEEE802.15.4 frames erroneously handed over to Zigbee dissector
|
| Product |
Wireshark
|
| Version |
2.2.1
|
| Hardware |
x86-64
|
| OS |
Windows 10
|
| Status |
UNCONFIRMED
|
| Severity |
Normal
|
| Priority |
Low
|
| Component |
Dissection engine (libwireshark)
|
| Assignee |
bugzilla-admin@wireshark.org
|
| Reporter |
arurke@gmail.com
|
Created attachment 14978 [details]
One 802.15.4 frame with 6lowpan and ICMPv6 which fail on 2.2.1 yet works on 2.0
Build Information:
Version 2.2.1 (v2.2.1-0-ga6fbd27 from master-2.2)
Copyright 1998-2016 Gerald Combs <gerald@wireshark.org> 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 WinPcap (4_1_3), with GLib 2.42.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.2.15, with Gcrypt 1.6.2, with MIT Kerberos, with GeoIP, with QtMultimedia,
with AirPcap.
Running on 64-bit Windows 10, build 14393, with locale Norwegian
Bokm�l_Norway.1252, 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) Core(TM) i5-3470 CPU @ 3.20GHz (with SSE4.2), with 16331MB of
physical memory.
Built using Microsoft Visual C++ 12.0 build 40629
Wireshark is Open Source Software released under the GNU General Public
License.
Check the man page and http://www.wireshark.org for more information.
--
This bug was introduced by commit https://code.wireshark.org/review/#/c/15921/
IEEE802.15.4 frames are erroneously handed over to Zigbee dissector causing
proper dissection (e.g. 6lowpan, see attachment for example), to fail.
This is caused by the definition of DISSECT_IEEE802154_OPTION_ZBOSS being 0x03
instead of 0x04, which causes the conditional Zigbee dissection
(packet-ieee802154.c:1549) to evaluate to true if OPTION_CC24XX (0x01) or
OPTION_LINUX (0x02) (i.e. not OPTION_ZBOSS) are set.
Will post a fix soon.
Disclaimer: I have not gone into the details of ZBOSS and don't know what it
actually is, so there is a tiny possibility this is intended behavior (ZBOSS
option being defined as a combination of OPTION_CC24XX and OPTION_LINUX), but
that seems HIGHLY unlikely (and it breaks my 6LoWPAN captures, so would need
some more work if that is the case)).
You are receiving this mail because:
- You are watching all bug changes.
