Wireshark-bugs: [Wireshark-bugs] [Bug 3657] New: FCS not detected, even if "Assume packets have

Date Prev · Date Next · Thread Prev · Thread Next
Date Index · Thread Index · Other Months · All Mailing Lists
From: bugzilla-daemon@xxxxxxxxxxxxx
Date: Fri, 3 Jul 2009 16:34:48 -0700 (PDT)
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=3657

           Summary: FCS not detected, even if "Assume packets have FCS" is
                    checked
           Product: Wireshark
           Version: 1.2.0
          Platform: x86
        OS/Version: All
            Status: NEW
          Severity: Normal
          Priority: Medium
         Component: Wireshark
        AssignedTo: wireshark-bugs@xxxxxxxxxxxxx
        ReportedBy: felipekk@xxxxxxxxx


Created an attachment (id=3250)
 --> (https://bugs.wireshark.org/bugzilla/attachment.cgi?id=3250)
Airodump-ng capture of a WEP authentication and network connection

Build Information:
Version 1.2.0 (SVN Rev 28753)

Compiled with GTK+ 2.16.2, with GLib 2.20.3, with WinPcap (version unknown),
with libz 1.2.3, without POSIX capabilities, with libpcre 7.0, with SMI 0.4.8,
with c-ares 1.6.0, with Lua 5.1, with GnuTLS 2.8.1, with Gcrypt 1.4.4, with MIT
Kerberos, with GeoIP, with PortAudio V19-devel (built Jun 15 2009), with
AirPcap.

Running on Windows Vista Service Pack 1, build 6001, with WinPcap version 4.1
beta5 (packet.dll version 4.1.0.1452), based on libpcap version 1.0.0, GnuTLS
2.8.1, Gcrypt 1.4.4, without AirPcap.

Built using Microsoft Visual C++ 9.0 build 30729
--
I've captured some packets with BackTrack4 and, when analyzing those, I've
noted a high number of malformed packets. After some observation, I've noticed
that Wireshark wasn't detecting the FCS at end, most of the times interpreting
that as a reserverd tag with a random lenght. 

Also, Wireshark is unable to decrypt those packets, probably because it tags
the FCS as WEP ICV. 

After running the packet capture though airdecap-ng, Wireshark tries to decrypt
the already decrypted packets. 

I've included the captures as well as the deciphered capture. You can see that
at packet 189 starts a shared-key authentication (WEP). The authentication is
successfull. I was able to manually decipher the encrypted challenge and I
could see the management frame header, the challenge and the WEP ICV, followed
by the FCS. 

For frame 193 (the encrypted challenge response), you have:

FCS: b7 fe 8e 2d
ICV: 3d 6e a1 70 (plaintext: 2c 34 f6 c3)

Plaintext Data:
0100030000001080b07ad18c6426c94b5d145c1ad74002b2694ba10c9a2f7f0214a6339b26cb5e37
46cf7ffa2e74a0fce6ca56b367383cf4a2e94e8e8ba2ee7648be09b363e005a73ffe0e77bf0109b5
ac9d1459c9b74408bef26c9bdbdb22ef8109b0810e745fe10a518f873ad39b27c0fffe0e7742173a
2d6aaba10e8a526b5ad557ba2ba4d8f52c34f6c3

WEP Key: 09269CD796563DBC186EE4B1E1

Based on this data, I believe there is a bug on detecting the FCS, maybe
related to the Radiotap header, which is causing the decryption of WEP packets
to not work.


-- 
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.