https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=16507
Bug ID: 16507
Summary: First ZigBee APS packet is not decrypted
Product: Wireshark
Version: 3.2.3
Hardware: x86
OS: Windows 10
Status: UNCONFIRMED
Severity: Major
Priority: Low
Component: Dumpcap
Assignee: bugzilla-ad...@wireshark.org
Reporter: hgiral...@gmail.com
Target Milestone: ---
Created attachment 17730
--> https://bugs.wireshark.org/bugzilla/attachment.cgi?id=17730&action=edit
ZB APS frame not decrypted
Build Information:
Version 3.2.3 (v3.2.3-0-gf39b50865a13)
Copyright 1998-2020 Gerald Combs <ger...@wireshark.org> and contributors.
License GPLv2+: GNU GPL version 2 or later
<https://www.gnu.org/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.12.6, with WinPcap SDK (WpdPack) 4.1.2, with GLib
2.52.3, with zlib 1.2.11, with SMI 0.4.8, with c-ares 1.15.0, with Lua 5.2.4,
with GnuTLS 3.6.3 and PKCS #11 support, with Gcrypt 1.8.3, with MIT Kerberos,
with MaxMind DB resolver, with nghttp2 1.39.2, with brotli, with LZ4, with
Zstandard, with Snappy, with libxml2 2.9.9, with QtMultimedia, with automatic
updates using WinSparkle 0.5.7, with AirPcap, with SpeexDSP (using bundled
resampler), with SBC, with SpanDSP, with bcg729.
Running on 64-bit Windows 10 (1903), build 18362, with Intel(R) Core(TM)
i7-8850H CPU @ 2.60GHz (with SSE4.2), with 16176 MB of physical memory, with
locale Spanish_Spain.1252, with light display mode, without HiDPI, with Npcap
version 0.9989, based on libpcap version 1.9.1, with GnuTLS 3.6.3, with Gcrypt
1.8.3, with brotli 1.0.2, without AirPcap, binary plugins supported (19
loaded). Built using Microsoft Visual Studio 2019 (VC++ 14.24, build 28316).
--
Sometimes (I could not determine under what conditions) the first encrypted ZB
APS packet is not decrypted. After the first one everything is fine. It is
really strange, because packets sent earlier in the other direction are
perfectly decrypted and they use the same network and link key.
You can see it in the attached evidence (pcapng attached):
Package number 39, with src 0x311f is not decrypted and package 51 is decrypted
with the same src and exactly the same keys.
I have opened the pcap with another dissector and using the same keys I can see
the package correctly.
Network and link keys:
7e67a96d05130e4fb60016e0716ed40d
d721cdfc733f108e0235e024864e71a7
P.S.: This failure also occurs in the shark.
--
You are receiving this mail because:
You are watching all bug changes.___________________________________________________________________________
Sent via: Wireshark-bugs mailing list <wireshark-bugs@wireshark.org>
Archives: https://www.wireshark.org/lists/wireshark-bugs
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs
mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe
