Kismet Wireless

Kismet Forums


Posted by:dragorn
Subject:Pcap Capture not capturing corrupt files?
Date:18:42:03 06/09/2016

> Hello Everyone,
> I have the following problem or issue:
> I am working with a modified version of Kismet Android PCAP Capture. I have set up a server, which sends UDP broadcast packets signed with a Magic Number sequence for identification.
> On the capturing side I have set up an IP-Filter and afterwards I am checking for the Magic Number sequence. After I have idetified "my packets" I am veryfying the UDP CRC Checksum. This works perfectly, but the thing is, I haven't been able to capture a UDP packet which has been corrupted.
> I have researched a bit and I'm kind of walking in the dark. It should be possible to monitor corrupt packets, but for some reasons my UDP packets just won't get corrupted. I have tried distancing myself from the sending source, having multiple other routers with a lot of traffic and all that stuff, but it still keeps monitoring intact packets and no corrupt ones.
> Is it that uncommon to capture a corrupted UDP packet?

I think, more or less, yes - it's that uncommon.

At the 802.11 layer, in-air corruption is detected and packet delivery is assured via the ack mechanism - every data frame, regardless of what it contains - is transmitted several times if it isn't ack'd by the other station. You'll only get a transmission error after 7 (if i recall correctly) retry failures, and even then it'll be a dropped packet, NOT a corrupted UDP packet.

If you really want to get corrupted frames, I know something like the ath9k PCI cards (and mpci, mpci-e, etc) will report them under Linux. Kismet does some deliberate checksumming of its own to deal with broken packets, which you can turn off - or you can capture raw with tcpdump or wireshark.

If you capture w/out FCS validation, you'll MOSTLY see corrupt beacons and other control frames. Data frames are, to an extent, protected by the collision avoidance mechanism built into dot11.

Really, a corrupted data frame which makes it through to the application layer should be extremely rare - not impossible, but far more rare than just dropping a frame.

Reply to this message