Kismet Wireless

Kismet Forums

 

Posted by:yj
Subject:Question on 802.11 "clear to send" frame capture
Date:22:04:23 30/06/2007

Hi,

I've found more clues on this problem when I printed out packet information
at the end of function PcapSource::Radiotap2KisPack(...). Hope this can help
you find out the problem.

When (frame_control.type == 1 && (frame_control.subtype == 12 || frame_control.subtype == 13) ), I say the packet is either a CTS or an
ACK packet,
I print out the pkt size indicated by packet->caplen. Here are
the results:
CTS is always 1090 bytes
ACK is 81 or 113 bytes
, which is very weird. I highly double if the libpcap is working correct.
FYI, I'm using libpcap-0.9.5 under linux.

For RTS packet, caplen shows 8 bytes without FCS. Though I thought it's 16 bytes, ethereal can view RTS frames without any problem.


Jun

> Hi,
>
> 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.
>
> Wh/cten 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,
>
> Jun


Reply to this message