Kismet Wireless

Kismet Forums


Posted by:yj
Subject:Question on 802.11 "clear to send" frame capture
Date:06:26:02 30/06/2007


Kismet works great for me for most of the time, but today I've got a problem when I tried to capture Request-to-send (RTS) and Clear-to-send (CTS) packets.

When I read the log file via wireshark, the number of RTS is correct, but I've got 3 times more CTS packets that what is expected. In addition, all those CTS packet are displayed as "Clear-to-send[Malformed Packet]" although I know for sure that some of them are correct CTS pkts because they have been successfully received.

I'm using madwifi_b source to capture traffic in an ad hoc network. In the ad hoc network, each node is equipped with an Aironet 350 card. Here is the detailed information viewed in ethereal:
No. Time Source Destination Protocol Info 57 5.054351 IEEE 802.11 Clear-to-send[Malformed Packet]
Frame 57 (8 bytes on wire, 8 bytes captured)
Arrival Time: Jun 30, 2007 00:25:34.849935000
[Time delta from previous packet: 0.000907000 seconds]
[Time since reference or first frame: 5.054351000 seconds]
Frame Number: 57
Packet Length: 8 bytes
Capture Length: 8 bytes
[Frame is marked: False]
[Protocols in frame: wlan]
IEEE 802.11
Type/Subtype: Clear-to-send (28)
Frame Control: 0x00C4 (Normal)
Version: 0
Type: Control frame (1)
Subtype: 12
Flags: 0x0
DS status: Not leaving DS or network is operating in AD-HOC mode (To DS: 0 From DS: 0) (0x00)
.... .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
.0.. .... = Protected flag: Data is not protected
0... .... = Order flag: Not strictly ordered
Duration: 312
[Malformed Packet: IEEE 802.11]

I'll be grateful if you'd provide any feedback on this issue.

Many thanks in advance,


Reply to this message