Kismet Wireless

Kismet Forums

 

Posted by:Luigi
Subject:Patch for "no networks" issue
Date:12:43:48 30/11/2015

I made a patch that I think could be helpful for those of you who are having one of the following issues with Kismet:

- Can't see any networks.
- Can see networks but most or all of them appear as Data Networks.
- Networks initially appear as Data Networks, and after some minutes their names appear.
- Lots of malformed packets in the dump file (if you open it in Wireshark you'll see that the FCS flag in PPI is wrong).
And so on.

This problem apparently happens a lot with the ath9k_htc driver. The cause appears to be incorrect alignment calculations in the Radiotap header, causing its Flags field (which contains the "has FCS" bit) to be incorrectly decoded, and Kismet assumes that the packet has no FCS, when in fact the ath9k_htc driver does include the FCS.

I also tested the patch with the rt2800pci driver (which worked fine before). I'm still testing this patch with other chipsets.

If you still get lots of malformed packets and you're using ath9k_htc, double-check that you enabled monitor mode without the fcsfail flag in the iw command.





diff -Naur kismet-2013-03-R1b/packetsource_pcap.cc kismet-2013-03-R1b_patched/packetsource_pcap.cc
--- kismet-2013-03-R1b/packetsource_pcap.cc 2013-03-27 11:41:48.000000000 -0300
+++ kismet-2013-03-R1b_patched/packetsource_pcap.cc 2015-11-30 09:13:49.034811616 -0300
@@ -673,7 +673,10 @@
eight11chunk->dlt = KDLT_IEEE802_11;

// iter = (u_char*)(last_presentp + 1);
- iter_start = iter = (u_char*)(last_presentp + 1);
+ iter = (u_char*)(last_presentp + 1);
+ // Alignment in Radiotap must be done from the beginning of the header,
+ // not from the byte following the last bitmap.
+ iter_start = (u_char*)(linkchunk->data);

for (bit0 = 0, presentp = &hdr->it_present; presentp <= last_presentp;
presentp++, bit0 += 32) {


Reply to this message