Kismet Wireless

Kismet Forums

 

Posted by:dom123
Subject:mac80211
Date:08:25:45 04/06/2011

> > Yep, I found that fix elsewhere on this forum and applied the change manually before building the image.. it didn't seem to make any difference however. I still get no packets when validatefcs=true is enabled on the source, either with the driver being manually set to ath9k or mac80211, or with no driver specification and kismet correctly choosing ath9k.
> >
> > Interesting that you have this working on AR71xx - what version of openwrt are you using, and what wireless card are you using?
> >
> > We are using a AR9220 which we believe to be the source of the problem.
> >
> > Incidentally, here is my packetsource_pcap.cc... i think this is correct?
> >
>
> Hi,
>
> Your packetsource_pcap.cc is correct.
>
> I use Atheros AR7161 & ar9280, kismet-2009-06-R1, OpenWrt Backfire 10.03 stable release.
> It makes sense to fix the driver ath9k, because CRC it has already been calculated. Use method 2.
> We need to find and fix the code in the files htc_drv_txrx.c and recv.c:
>
> Was:
> if (ah->is_monitoring)
> {
> if (rx_stats->rs_status &
> ~(ATH9K_RXERR_DECRYPT | ATH9K_RXERR_MIC |
> ATH9K_RXERR_CRC))
> return false;
>
> Needed:
> if (ah->is_monitoring)
> {
> if (rx_stats->rs_status &
> ~(ATH9K_RXERR_DECRYPT | ATH9K_RXERR_MIC /*|
> ATH9K_RXERR_CRC*/))
> return false;
>
> May be slightly out of such a code. Need toseek ATH9K_RXERR_CRC.
> And then you can disable the check CRC in kismet.

Thank you again!! This seems to be working.

Can you help me understand the implications of this change please? I have both option 1 and option 2 implemented, and validatefcs is not included in the drone source definition.

Does the option1 and option2 change mean that CRC errors are ignored?


Reply to this message