Steve,
According to the capture, the data is protected:
=====
[...]
Flags: 0x41
DS status: Frame from STA to DS via an AP (To DS: 1 From
DS: 0) (0x01)
.... .0.. = More Fragments: This is the last fragment
.... 0... = Retry: Frame is not being retransmitted
...0 .... = PWR MGT: STA will stay up
..0. .... = More Data: No data buffered
.1.. .... = Protected flag: Data is protected
0... .... = Order flag: Not strictly ordered
[...]
=====
You may need to setup the WEP key in Wireshark first to decrypt the data packet.
Regards,
Kam-Yung
On 8/11/06, Steve Magoun <steve@xxxxxxxxxx> wrote:
Hi,
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 (enclosed;
see below) 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. What am I
doing wrong?
802.11 frame exported as text:
Thanks,
Steve
--
Soh Kam Yung
my simpy links: (http://www.simpy.com/user/kysoh/links)
