[bugzilla-daemon@xxxxxxxxxxxxx]

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.