Kismet Wireless

Kismet Forums


Posted by:dragorn
Subject:Kismet ath9k issues (ioctl+DMA+stops reporting packets after a while)
Date:19:37:28 16/03/2010

> Hello Kismet Community!
> (system info, log files, etc at the end of this post)
> I having troubles getting Kismet properly working (though it does not completely refuses work)
> I have done seriouse and intense search for solutions, without any results yet.
> The Problems are quite confusing. From a lusers point of view, the visible part of the Problem is Kismet stopping reporting Packets after some time, 20-40 minutes.
> While chasing a solution for this, i found some suspicious msgs in my kernel log, like: (dmesg)
> [ 5884.960200] ath: DMA failed to stop in 10 ms AR_CR=0x00000024A R_DIAG_SW=0x00000020
> which i just cant get rid of. I changed the DMA timeouts to larger values in the ath9k driver module source, no effect.

This is, unfortunately, a driver bug, and nothing that Kismet can do will fix it. Try the latest drivers (either by upgrading your kernel or by using the back-ported bleeding edge drivers from the compat-wireless package, which may or may not exist for your system, check for more info).

If you're using an older (pre-2.6.31/32 kernel) upgrading has a very high chance of solving this. On newer kernels... you may still have luck. If that still doesn't work, try slowing down channel hopping, or turning it off completely. That won't be a solution, but it may help.

> After some further searching/testing, i noticed that i get another error message from kismet_server, but only at the _first_ launch of kismet_server (i.e. to reproduce i have to reload the kernel module)
> The error message is as follows:
> ERROR: channel get ioctl failed 22:Invalid argument

That's unrelated - Kismet tries multiple methods to figure out what card you have, and will try to fetch the channel lists several ways. One of them failed, it's not a problem.

And yes - modern kismets support dynamic adding of sources, so they keep running even once it has failed. In your case, however, I'm not sure the device is even "failing", at least, not in a way visible to the application. It's failing to report packets, but that's not necessarily a failure condition unless something else happens. It's a driver bug that causes it to silently stop reporting data.


Reply to this message