Kismet Wireless

Kismet Forums

 

Posted by:schism
Subject:2009-05 processor utilization
Date:22:38:10 22/06/2009

I've spent the weekend chasing what I initially thought was a busy loop in kismet_server.cc, and have finally come up against a dead end. I think this is the same problem that change #2853 tried to address, but it wasn't successful. This has been tested with an ath5k and an ipw3945.

Precise behavior:
Within a couple of iterations of the main loop in kismet_server, the select() calls start returning in <50 microseconds, eliminating the benefit of using select() and creating a busy loop. The culprit seems that the pcap FD select() is polling indicates there is data, but when going to read data (with pcap_dispatch()), there isn't any. Change #2853 notes this and tries to address it by disabling a source with more than 100 such 'zeropoll' states for 10 seconds - problem being that the cards are still present and in good state. 10 seconds later, they get ~100 more passes and are shut off again.

I have no idea how to fix this; I've tried just about everything: using pcap_set_rfmon (didn't work, broke other device interactions), disabling polling of the pcap handles (10 PPS doesn't get you very far), even just disabling the zeropoll checking (still have the busy loop). Suggestions?


Reply to this message