Kismet Wireless

Kismet Forums


Posted by:dragorn
Subject:Kismet doesn't recognize ath10k_pci
Date:16:07:00 06/01/2017

> "Didn't understand driver 'ath10k_pci' for interface 'wlp3s0', but it looks like a mach 80211 device so Kismet will use the generic options for it." No further errors show up (although there is an info message saying "channel get ioctl failed 61: No data available").

This you can ignore - it doesn't know for sure what the ath10k is, but it knows the driver is behaving like mac80211 so it'll handle it. A bunch of this code is being phased out in the new capture system that's about to go in, so it's not worth doing another release just to add that.

> Eventually, I get a read complaining that it "failed to read a packet from wlp3s0. The interface is no longer up. Usually this happens when a DHCP client daemon is left running and times out, turning off the interface". I'm fairly certain that isn't the case, but am still looking into it.

This definitely means something downed the interface, but the rest of the message is just a best guess - *something* did a link down on the interface, that much is definite. It could be dhcp, network manager, some other network management tool, etc.

Since it's an ath10k, it could also be the firmware dropping dead, and the kernel crashing the card and putting it in down state - take a look at 'dmesg' and see what it says.

Unfortunately, I've done a lot of testing on the ath10k, and it's really not one of my favorite cards. I find it spews a TON of absolute GARBAGE data; it won't pass fcs bytes up to let kismet validate packets, and it's own packet validation is provably wrong - it sets fcs-valid flags on visibly broken and corrupt packets.

I've also found the 10k to be *really* unstable - it's highly highly kernel version dependent, and often crashes the microcode on the card.

Other fun things it does seem to include a lag on the channel set - either the driver is saying the channel set is complete before it is, or the firmware is telling the kernel driver it's complete before it is, but the end result is the radiotap headers saying the new channel while the radio is still tuned to the old channel - leading to fun things in Kismet like the frequency graph showing a smear between 2.4 and 5ghz on the same network.

I find the ath9k to be a MUCH more stable card to use and prefer it in almost all situations - if you can get one of the ath9k 3x3 cards that's even better. You lose 802.11ac, but I've yet to see useful 11ac data capture from anything.

If you want to stay in the 11AC realm, there's also the intel 8265. It requires a m2 slot (or m2 adapter) and the new ultra-tiny u.fl variant antenna connections, unfortunately, but it's *relatively* stable. It's still not as good as the ath9k is.

If you're feeling particularly daring, I'd suggest checking out the master branch of git and building kismet from that; this has the all new web ui, and a lot of work on processing packets from the ath10k weirdo broken stream; however it's heavily under development, may not work at any given time, and while pcap logging works fine, xml and text logging does not (however you get the REST interface which gives you live json access, so if you were scraping the XML you could get it that way just as easily or even more easily)

Hope that helps,

Reply to this message