Wireshark-bugs: [Wireshark-bugs] [Bug 12024] New: IEEE802.11 FCS issue preventing WPA decryption
Date: Sun, 17 Jan 2016 21:11:17 +0000
Bug ID | 12024 |
---|---|
Summary | IEEE802.11 FCS issue preventing WPA decryption |
Product | Wireshark |
Version | 2.0.1 |
Hardware | x86 |
OS | Windows 7 |
Status | CONFIRMED |
Severity | Major |
Priority | Low |
Component | Dissection engine (libwireshark) |
Assignee | bugzilla-admin@wireshark.org |
Reporter | sindelka@marconi.ttc.cz |
Created attachment 14254 [details] monitor mode capture illustrating incorrect FCS with eapol hshk and several tcp sessions Build Information: Version 2.0.1 (v2.0.1-0-g59ea380 from master-2.0) Copyright 1998-2015 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.3.2, with WinPcap (4_1_3), with libz 1.2.8, 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 QtMultimedia, with AirPcap. Running on 64-bit Windows 7 Service Pack 1, build 7601, with locale C, 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-3210M CPU @ 2.50GHz (with SSE4.2), with 8141MB of physical memory. Built using Microsoft Visual C++ 12.0 build 31101 -- In a monitor mode capture, Wireshark deems wrong the FCS of 802.11 frames sent from a Technicolor (UPC) AP to a Samsung mobile phone. Only "QoS data" and "data" packets suffer from this, other frame types seem unaffected. I assume it is a bug of Wireshark because - neither the phone nor other devices receiving frames from that AP exhibit any problems, so at least the contents of the packets must be fine if not the FCS, - Wireshark doesn't complain about the FCS of any packets the phone sends itself. So my assumption is that the ieee80211 dissector possibly doesn't include some rarely used bit, which Technicolor uses and Samsung doesn't, into the FCS calculation, or irons it down to 0 before calculating the FCS, whatever. The other possibility would of course be that the wireless driver in monitoring mode malforms the packets if they contain some rarely used bit . A secondary issue highlighted by the primary one is that no combination of "Assume packets have FCS" and "Validate the FCS checksum if possible" settings makes Wireshark decrypt such packets. wpa-pwd for the attached sample capture taken at Mac: YJHGBQXC:UPC2323467 trying to add an attachment
You are receiving this mail because:
- You are watching all bug changes.
- Prev by Date: [Wireshark-bugs] [Bug 7719] Bluetooth: Add BNEP dissector
- Next by Date: [Wireshark-bugs] [Bug 12006] desegment_tcp can't defragment PDU if fragments come in wrong order
- Previous by thread: [Wireshark-bugs] [Bug 7719] Bluetooth: Add BNEP dissector
- Next by thread: [Wireshark-bugs] [Bug 11983] Wireshark static out-of-bounds read in hiqnet_display_data
- Index(es):