Summary
I was running into a problem running on the origin/main where after enabling a USB wifi datasource, the commands to lock to a channel would begin taking a very long time to complete. The Kismet logs would just say the "Command failed to complete," but if I waited long enough, the channel would eventually lock.
Environment
Commit: bca676c
Branch: origin/main
Platform: Raspberry Pi 4B, 4GB RAM
uname: Linux 6.12.34+rpt-rpi-v8 #1 SMP PREEMPT Debian 1:6.12.34-1+rpt1~bookworm (2025-06-26) aarch64 unknown unknown GNU/Linux
USB WiFi device: ALFA Networks AWUS036ACM
Steps to reproduce
make; sudo make suidinstallsudo ./kismet --no-ncurses-wrapper --debug --confdir /etc/kismet- Enable the wlan1 datasource in the web UI
- Just keep locking to channels until the failures start, usually in less than 5 minutes.
Suspected Cause
I think there's a bug in capture_framework.c when it reads commands sent from the main kismet process: https://github.com/kismetwireless/kismet/blob/bca676c/capture_framework.c#L2907-L2964
When the read call happens, it will read however much data is available and write that all to the ring buffer. Once it's done, it will process at most one command on line 2957 before moving on to write responses. If you happened to read more than one message before moving on to write, it will just sit in the ring buffer until the next time through the loop. The second time through the loop, if there was no data to read, triggering an EAGAIN error, you will break out of the command processing loop before processing the command that was not handled in the previous iteration. Over time, these messages build up in the ring buffer unprocessed until the commands eventually "time out" from the main kismet processes's perspective. But once the ring buffer finally catches up to that command you were waiting on (like a channel lock), it will actually happen.
I tested this change locally to see if it fixed my problem, and after retrieving over 300 messages from the main kismet process, I wasn't seeing any delay with message processing. Without this change, it would only take around 32 KIS_EXTERNAL_V3_CMD_PING messages for me to start noticeably falling behind the requests.
goto cap_loop_fail;
}
- /* See if we have a complete packet to do something with */
- if (cf_handle_rb_rx_data(caph) < 0) {
+ /* Handle all messages as long as we have a complete packet to do something with */
+ int cfret = 1;
+ while (cfret > 0) {
+ cfret = cf_handle_rb_rx_data(caph);
+ }
+ if (cfret < 0) {
/* Enter spindown if processing an incoming packet failed */
fprintf(stderr, "FATAL: Datasource helper (%s) failed, could not process incoming control packet.\n",
caph->capsource_type);I'm not very familiar with the kismet code base, so I'm not sure what kind of unintended consequences this change would cause.
Summary
I was running into a problem running on the
origin/mainwhere after enabling a USB wifi datasource, the commands to lock to a channel would begin taking a very long time to complete. The Kismet logs would just say the "Command failed to complete," but if I waited long enough, the channel would eventually lock.Environment
Commit: bca676c
Branch:
origin/mainPlatform: Raspberry Pi 4B, 4GB RAM
uname:
Linux 6.12.34+rpt-rpi-v8 #1 SMP PREEMPT Debian 1:6.12.34-1+rpt1~bookworm (2025-06-26) aarch64 unknown unknown GNU/LinuxUSB WiFi device: ALFA Networks AWUS036ACM
Steps to reproduce
make; sudo make suidinstallsudo ./kismet --no-ncurses-wrapper --debug --confdir /etc/kismetSuspected Cause
I think there's a bug in
capture_framework.cwhen it reads commands sent from the main kismet process: https://github.com/kismetwireless/kismet/blob/bca676c/capture_framework.c#L2907-L2964When the
readcall happens, it will read however much data is available and write that all to the ring buffer. Once it's done, it will process at most one command on line 2957 before moving on to write responses. If you happened to read more than one message before moving on to write, it will just sit in the ring buffer until the next time through the loop. The second time through the loop, if there was no data to read, triggering anEAGAINerror, you will break out of the command processing loop before processing the command that was not handled in the previous iteration. Over time, these messages build up in the ring buffer unprocessed until the commands eventually "time out" from the main kismet processes's perspective. But once the ring buffer finally catches up to that command you were waiting on (like a channel lock), it will actually happen.I tested this change locally to see if it fixed my problem, and after retrieving over 300 messages from the main kismet process, I wasn't seeing any delay with message processing. Without this change, it would only take around 32
KIS_EXTERNAL_V3_CMD_PINGmessages for me to start noticeably falling behind the requests.I'm not very familiar with the kismet code base, so I'm not sure what kind of unintended consequences this change would cause.