Kismet Wireless

Kismet Forums

 

Posted by:dom123
Subject:mac80211 driver + 802.11n
Date:11:36:49 13/05/2011

> > > So I made some progress..
> > >
> > > I noticed in a capture file that the bad packets had a bad checksum, so I tried to enable valdiation in kismet by configurting the ncsource as follows:
> > >
> > > ncsource=wlan0:name=ath9k,hop=true,validatefcs=true
> > >
> > > However, this caused me to receive no networks. It seemed every packet was failing the checksum. I took a pcap file and ran it on my desktop in the same way and it worked, which made me think it was an endian problem.
> > >
> > > Sure enough, I noticed the crc function is called "crc32_le_80211()" (little endian).
> > >
> > > I edited packetsource_pcap.cc, added #include <asm/byteorder.h>.
> > >
> > > Everywhere that crc32_le_80211() is called, I wrap it in __le32_to_cpu();
> > >
> > > Now with validatefcs turned on, Kismet sees valid packets.
> > >
> > > This seems to fix the problem for me. As best as I can tell, the ath9k driver in monitor mode sends along packets that fail their checksum, which is weird. It might be a bug in their driver code, since they have a special mode to enable fcs failing packets ("iw wlan0 set monitor fcsfail").
> >
> >
> >
> > Hey Cutter,
> >
> > Been following your posts about the ath9k driver. Very interested in the progress you have made, as I am still getting corrupt frames. Have tried to edit the kismet source as per your information. Unfortunately my programming skills are very limited. I am a bit confused on how to "wrap" the crc32_le_80211().
> >
> > Would be awesome if you could dump you edited packetsource_pcap.cc file.
> >
> > Thanks!
> > Regards Tom
>
> Here's an actual patch:
>
> --- ../kismet-devel/packetsource_pcap.cc 2010-08-30 18:03:25.247302314 -0400
> +++ ./packetsource_pcap.cc 2010-10-14 17:42:19.303746024 -0400
> @@ -26,6 +26,7 @@
> #include <sys/stat.h>
> #include <sys/ioctl.h>
> #include <sys/socket.h>
> +#include <asm/byteorder.h>
>
> #include "gpscore.h"
>
> @@ -359,8 +360,8 @@
> if (validate_fcs && fcschunk != NULL) {
> // Compare it and flag the packet
> uint32_t calc_crc =
> - crc32_le_80211(globalreg->crc32_table, eight11chunk->data,
> - eight11chunk->length);
> + __le32_to_cpu(crc32_le_80211(globalreg->crc32_table, eight11chunk->data,
> + eight11chunk->length));
>
> if (memcmp(fcschunk->fcsp, &calc_crc, 4)) {
> packet->error = 1;
> @@ -513,8 +514,8 @@
> if (validate_fcs && fcschunk != NULL) {
> // Compare it and flag the packet
> uint32_t calc_crc =
> - crc32_le_80211(globalreg->crc32_table, eight11chunk->data,
> - eight11chunk->length);
> + __le32_to_cpu(crc32_le_80211(globalreg->crc32_table, eight11chunk->data,
> + eight11chunk->length));
>
> if (memcmp(fcschunk->fcsp, &calc_crc, 4)) {
> packet->error = 1;
> @@ -819,8 +820,8 @@
> if (validate_fcs && fcschunk != NULL) {
> // Compare it and flag the packet
> uint32_t calc_crc =
> - crc32_le_80211(globalreg->crc32_table, eight11chunk->data,
> - eight11chunk->length);
> + __le32_to_cpu(crc32_le_80211(globalreg->crc32_table, eight11chunk->data,
> + eight11chunk->length));
>
> if (memcmp(fcschunk->fcsp, &calc_crc, 4)) {
> packet->error = 1;
> @@ -1058,8 +1059,8 @@
> if (validate_fcs && fcschunk != NULL) {
> // Compare it and flag the packet
> uint32_t calc_crc =
> - crc32_le_80211(globalreg->crc32_table, eight11chunk->data,
> - eight11chunk->length);
> + __le32_to_cpu(crc32_le_80211(globalreg->crc32_table, eight11chunk->data,
> + eight11chunk->length));
>
> if (memcmp(fcschunk->fcsp, &calc_crc, 4)) {
> packet->error = 1;
>
>
> By "wrap" I mean put "__le32_to_cpu( .... )" around it.

Hi Cutter - I have applied your patch but it didn't seem to fix the issue for me.. can you confirm if you still needed validatefcs=true on the drone ncsource? Also what version did you apply this to, i'm using 2010-07-R1-1 on the drones.. Thanks!


Reply to this message