http://bugs.wireshark.org/bugzilla/show_bug.cgi?id=1041
Summary: 802.11 frame data not decoded
Product: Wireshark
Version: 0.99.2
Platform: Macintosh
OS/Version: Mac OS X 10.4
Status: NEW
Severity: Normal
Priority: Low
Component: Wireshark
AssignedTo: wireshark-bugs@xxxxxxxxxxxxx
ReportedBy: steve@xxxxxxxxxx
I'm using Wireshark 0.99.2 to view some 802.11 traffic captured by Kismet
2006-04-R1. Wireshark correctly interprets the Kismet output as IEEE 802.11
frames but doesn't fully decode the data inside - the packet details pane has
only "Frame," "IEEE 802.11," and "Data" sections. I'm tracing some DHCP
problems, and I was hoping Wireshark would break down the 580-byte data section
in my sample as IP/UDP/DHCP rather than just a raw hex dump. I checked the data
section by hand and it appears that it is indeed a DHCP request message (as I
expected). This problem affects all non- management packets in my dump file.
I've tried this with the same results using Ethereal 0.10-12, 0.99.0, and
Wireshark 0.99.2 (all on OS X 10.4.7). Fiddling with the Wireshark protocol
options for IEEE 802.11 didn't help.
I'm on a WEP network, but I have Kismet configured to decrypt traffic on the
fly. As you can see from the packet dump, the data is indeed unencrypted by the
time it gets to Wireshark. Just in case I tried adding the WEP key to Wireshark
but that didn't help. Neither did setting the "Ignore WEP Flag" option
(although the Ignore WEP Flag option did result in a Logical-Link Control entry
in the packet details pane, the rest of the data section wasn't decoded).
--
Configure bugmail: http://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
