Kismet Wireless

Kismet Forums

 

Posted by:dragorn
Subject:2009-05 processor utilization
Date:23:38:13 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?

Are you using libpcap-cvs? This seems to return bad selectable FDs (tcpdump and wireshark suffer the same problem).

Zeropoll was designed to catch libpcap-1.0.0 not returning error states on disconnected devices, where it leaves a fd that is high but never returns packets (again, tcpdump and wireshark suffer from the same with 1.0.0 here).

The only time I've seen the behavior you describe is with CVS versions on libpcap newer than 1.0.0 release, and goes away when you go back to 1.0.0.

-m


Reply to this message