Kismet Wireless

Kismet Forums

 

Posted by:cutter409
Subject:mac80211 driver + 802.11n
Date:21:56:50 14/10/2010

> > > >
> > > > Strangely, if I put the same card into a laptop instead of using a single board computer running OpenWRT, the corrupt packet issue goes away.
> > > >
> > > > I'm so confused.
> > >
> > > what's the SBC? Is it intel, or is it some other platform?
> > >
> > > Get some (short-ish) pcaps, gzip them, and put them somewhere or email them to me, from the SBC (using tcpdump)
> > >
> > > -m
> >
> > It's an Intel IXP, so arm. I'll send you an email after I get the capture.
>
>
> Just sent an email about what I've been able to learn, and an example pcap.

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").


Reply to this message