FATAL: Capture source 1377 did not get PING from Kismet for over 15 seconds

[96611229]

Hi,

Seeing this happen when I load kismet file.

INFO: KismetDB 'Kismet-20210316-15-16-34-1.kismet' closed, all packets and 
      data processed.
Uncaught exception "potential deadlock: mutex kis_database(kismetlog) not available within timeout period for op UNKNOWN"
Stack trace (most recent call last):
Uncaught exception "std::exception"
Uncaught exception "potential deadlock: mutex kis_database(kismetlog) not available within timeout period for op UNKNOWN"
Stack trace (most recent call last):
Uncaught exception "std::exception"
Abort trap: 6
FATAL: Capture source 1377 did not get PING from Kismet for over 15 seconds; shutting down

Running Kismet 2021-00-GIT. Caveat is that I'm running this on MacOS while the actual capture file was created on Linux. Please let me know if you need more info. Thanks for your great work and effort 🤘

[96611229]

I can also say that it does not happen on Linux where I captured it, when I try to open with kismet -c.

[kismetwireless]

Unfortunately I can't replicate this with the latest code; give it a try with the current git main code is all I can suggest; I'm able to reply existing capture files on macos without a problem.

If it still fails, I'll need some sort of debug info - unfortunately as far as I know stock GDB doesn't work on macos (at least not without a lot of hurdles, and then, not the same - but i could be wrong) so you can't follow the existing debug instructions, but I don't use macos enough to know what the equivalent is in their environment.

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Tuesday, March 16th, 2021 at 4:05 PM, 96611229 @.***> wrote:

I can also say that it does not happen on Linux where I captured it, when I try to open with kismet -c.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[96611229]

Thanks for fast response! Yeah, it's likely macos related. I used another file and the error is below. I compiled it on OS X using your guide and homebrew, if it helps.

encountered an  error: IPC connection closed
FATAL: kismetdb log couldn't finish a database transaction within the timeout window for threads (30 seconds).  Usually this happens when the disk you are logging to can not perform adequately, such as a micro SD.  Try moving logging to a USB device.

*** KISMET IS SHUTTING DOWN ***

*** KISMET HAS ENCOUNTERED A FATAL ERROR AND CANNOT CONTINUE.  ***
Shutting down plugins...
WARNING: Kismet changes the configuration of network devices.
         In most cases you will need to restart networking for
         your interface (varies per distribution/OS, but 
         typically one of:
         sudo service networking restart
         sudo /etc/init.d/networking restart
         or
         nmcli device set [device] managed true

Kismet exiting.

It's not really a big deal, I can replay on linux but figured this might be a know issue. Feel free to close it if not much can be done at this point. Thanks!

[dragorn]

If you haven't tried with the latest git - as in, this afternoons - give it one more shot, since a GPS regression got fixed.

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Tuesday, March 16th, 2021 at 5:25 PM, 96611229 @.***> wrote:

Thanks for fast response! Yeah, it's likely macos related. I used another file and the error is below. I compiled it on OS X using your guide and homebrew, if it helps.

encountered an error: IPC connection closed FATAL: kismetdb log couldn't finish a database transaction within the timeout window for threads (30 seconds). Usually this happens when the disk you are logging to can not perform adequately, such as a micro SD. Try moving logging to a USB device.

KISMET IS SHUTTING DOWN

KISMET HAS ENCOUNTERED A FATAL ERROR AND CANNOT CONTINUE. Shutting down plugins... WARNING: Kismet changes the configuration of network devices. In most cases you will need to restart networking for your interface (varies per distribution/OS, but typically one of: sudo service networking restart sudo /etc/init.d/networking restart or nmcli device set [device] managed true

Kismet exiting.

It's not really a big deal, I can replay on linux but figured this might be a know issue. Feel free to close it if not much can be done at this point. Thanks!

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[96611229]

Hi,

I just pulled latest git and compiled it again. During ./config I saw this, perhaps it's related:

Built-in Debug: partial - Missing libdw or libbfd will not print full stacks on crash

However it still happens sadly. More info though:

       0-58-58-1.kismet:SQL logic error
INFO: KismetDB '/Users/user/Desktop/Kismet-20210317-14-51-13-1.kismet' 
      closed, all packets and data processed.
Uncaught exception "potential deadlock: mutex kis_database(kismetlog) not available within timeout period for op UNKNOWN"
Stack trace (most recent call last):
Uncaught exception "std::exception"
Uncaught exception "potential deadlock: mutex kis_database(kismetlog) not available within timeout period for op UNKNOWN"
Stack trace (most recent call last):
Uncaught exception "std::exception"
Abort trap: 6
FATAL: Capture source 3739 did not get PING from Kismet for over 15 seconds; shutting down

Thanks for all your help!

[michaelmohamed]

I received a similar error. I am experiencing it when writing to a USB 3.0 drive.

[Logs]    [3/27/2021, 12:03:32 AM] [] FATAL: kismetdb log couldn't finish a database transaction within the timeout window for threads (30 seconds).  Usually this happens when the disk you are logging to can not perform adequately, such as a micro SD.  Try moving logging to a USB device.FATAL: kismetdb log couldn't finish a database transaction within the timeout window for threads (30 seconds).  Usually this happens when the disk you are logging to can not perform adequately, such as a micro SD.  Try moving logging to a USB device.Uncaught exception "potential deadlock: mutex kis_database(kismetlog) not available within timeout period for op UNKNOWN"
[Logs]    [3/27/2021, 12:03:32 AM] [] Stack trace (most recent call last) in thread 114:
[Logs]    [3/27/2021, 12:03:32 AM] [] FATAL: kismetdb log couldn't finish a database transaction within the timeout window for threads (30 seconds).  Usually this happens when the disk you are logging to can not perform adequately, such as a micro SD.  Try moving logging to a USB device.#8    Object "/lib/aarch64-linux-gnu/libpthread-2.27.so, at 0x7f8e79e087, in start_thread

[michaelmohamed]

Here is some debug output

[Logs] [3/27/2021, 12:48:36 AM] [] FATAL: kismetdb log couldn't finish a database transaction within the timeout window for threads (30 seconds). Usually this happens when the disk you are logging to can not perform adequately, such as a micro SD. Try moving logging to a USB device.FATAL: kismetdb log couldn't finish a database transaction within the timeout window for threads (30 seconds). Usually this happens when the disk you are logging to can not perform adequately, such as a micro SD. Try moving logging to a USB device.#10 Object "/lib/aarch64-linux-gnu/libpthread-2.27.so, at 0x7fb2c58087, in start_thread [Logs] [3/27/2021, 12:48:36 AM] [] #9 Object "/usr/lib/aarch64-linux-gnu/libstdc++.so.6.0.25, at 0x7fb2d82e93, in [Logs] [3/27/2021, 12:48:37 AM] [] #8 | Source "/usr/include/c++/7/thread", line 186, in operator() [Logs] [3/27/2021, 12:48:37 AM] [] | 185: void [Logs] [3/27/2021, 12:48:37 AM] [] | > 186: _M_run() { _M_func(); } [Logs] [3/27/2021, 12:48:37 AM] [] | 187: }; [Logs] [3/27/2021, 12:48:37 AM] [] | Source "/usr/include/c++/7/thread", line 243, in _M_invoke<0> [Logs] [3/27/2021, 12:48:37 AM] [] | 241: noexcept(noexcept(std::declval<_Invoker&>()._M_invoke(_Indices()))) [Logs] [3/27/2021, 12:48:37 AM] [] | 242: -> decltype(std::declval<_Invoker&>()._M_invoke(_Indices())) [Logs] [3/27/2021, 12:48:37 AM] [] | > 243: { return _M_invoke(_Indices()); } [Logs] [3/27/2021, 12:48:37 AM] [] | 244: }; [Logs] [3/27/2021, 12:48:37 AM] [] | Source "/usr/include/c++/7/thread", line 234, in invoke<packet_chain::packet_chain()::<lambda()> > [Logs] [3/27/2021, 12:48:37 AM] [] | 232: noexcept(noexcept(std::invoke(_S_declval<_Ind>()...))) [Logs] [3/27/2021, 12:48:37 AM] [] | 233: -> decltype(std::invoke(_S_declval<_Ind>()...)) [Logs] [3/27/2021, 12:48:37 AM] [] | > 234: { return std::invoke(std::get<_Ind>(std::move(_M_t))...); } [Logs] [3/27/2021, 12:48:37 AM] [] | 235: [Logs] [3/27/2021, 12:48:37 AM] [] | 236: using _Indices [Logs] [3/27/2021, 12:48:37 AM] [] | Source "/usr/include/c++/7/bits/invoke.h", line 95, in invoke_impl<void, packet_chain::packet_chain()::<lambda()> > [Logs] [3/27/2021, 12:48:37 AM] [] | 93: using type = typename result::type; [Logs] [3/27/2021, 12:48:37 AM] [] | 94: using tag = typename result::invoke_type; [Logs] [3/27/2021, 12:48:37 AM] [] | > 95: return std::invoke_impl<__type>(__tag{}, std::forward<_Callable>(fn), [Logs] [3/27/2021, 12:48:37 AM] [] | 96: std::forward<_Args>(args)...); [Logs] [3/27/2021, 12:48:37 AM] [] | 97: } [Logs] [3/27/2021, 12:48:37 AM] [] | Source "/usr/include/c++/7/bits/invoke.h", line 60, in operator() [Logs] [3/27/2021, 12:48:37 AM] [] | 58: constexpr _Res [Logs] [3/27/2021, 12:48:37 AM] [] | 59: __invoke_impl(invoke_other, _Fn&& f, _Args&&... __args) [Logs] [3/27/2021, 12:48:37 AM] [] | > 60: { return std::forward<_Fn>(f)(std::forward<_Args>(args)...); } [Logs] [3/27/2021, 12:48:37 AM] [] | 61: [Logs] [3/27/2021, 12:48:37 AM] [] | 62: template<typename _Res, typename _MemFun, typename _Tp, typename... _Args> [Logs] [3/27/2021, 12:48:37 AM] [] Source "/kismet/packetchain.cc", line 159, in _M_run [Logs] [3/27/2021, 12:48:37 AM] [] 156: for (int n = 0; n < nt; n++) { [Logs] [3/27/2021, 12:48:37 AM] [] 157: packet_threads.emplace_back(std::thread([this, nt, n]() { [Logs] [3/27/2021, 12:48:37 AM] [] 158: thread_set_process_name(fmt::format("packethandler {}/{}", n, nt)); [Logs] [3/27/2021, 12:48:37 AM] [] > 159: packet_queue_processor(); [Logs] [3/27/2021, 12:48:37 AM] [] 160: })); [Logs] [3/27/2021, 12:48:37 AM] [] 161: } [Logs] [3/27/2021, 12:48:37 AM] [] #7 Source "/kismet/packetchain.cc", line 339, in packet_queue_processor [Logs] [3/27/2021, 12:48:37 AM] [] 337: for (const auto& pcl : classifier_chain) { [Logs] [3/27/2021, 12:48:37 AM] [] 338: if (pcl->callback != nullptr) [Logs] [3/27/2021, 12:48:37 AM] [] > 339: pcl->callback(Globalreg::globalreg, pcl->auxdata, packet); [Logs] [3/27/2021, 12:48:37 AM] [] 340: else if (pcl->l_callback != nullptr) [Logs] [3/27/2021, 12:48:37 AM] [] 341: pcl->l_callback(packet); [Logs] [3/27/2021, 12:48:37 AM] [] 342: } [Logs] [3/27/2021, 12:48:37 AM] [] #6 Source "/kismet/phy_80211.cc", line 1054, in packet_dot11_common_classifier [Logs] [3/27/2021, 12:48:37 AM] [] 1051: } [Logs] [3/27/2021, 12:48:37 AM] [] 1052: [Logs] [3/27/2021, 12:48:37 AM] [] 1053: bssid_dev = [Logs] [3/27/2021, 12:48:37 AM] [] >1054: d11phy->devicetracker->update_common_device(commoninfo, [Logs] [3/27/2021, 12:48:37 AM] [] 1055: dot11info->bssid_mac, d11phy, in_pack, [Logs] [3/27/2021, 12:48:37 AM] [] 1056: bflags, [Logs] [3/27/2021, 12:48:37 AM] [] 1057: "Wi-Fi Device"); [Logs] [3/27/2021, 12:48:37 AM] [] #5 Source "/kismet/devicetracker.cc", line 1227, in update_common_device [Logs] [3/27/2021, 12:48:37 AM] [] 1225: // Lock before we look up the device, we can't have two threads making a new [Logs] [3/27/2021, 12:48:37 AM] [] 1226: // device record for the same device [Logs] [3/27/2021, 12:48:38 AM] [] >1227: ul_list.lock(); [Logs] [3/27/2021, 12:48:38 AM] [] 1228: [Logs] [3/27/2021, 12:48:38 AM] [] 1229: if ((device = fetch_device_nr(key)) == NULL) { [Logs] [3/27/2021, 12:48:38 AM] [] 1230: if (in_flags & UCD_UPDATE_EXISTING_ONLY) [Logs] [3/27/2021, 12:48:38 AM] [] #4 Source "/kismet/kis_mutex.h", line 285, in lock [Logs] [3/27/2021, 12:48:38 AM] [] 283: if (!mutex.try_lock_for(std::chrono::seconds(KIS_THREAD_TIMEOUT))) [Logs] [3/27/2021, 12:48:38 AM] [] 284: throw std::runtime_error(fmt::format("potential deadlock: mutex {} not available within " [Logs] [3/27/2021, 12:48:38 AM] [] > 285: "timeout period for op {}", mutex.get_name(), op)); [Logs] [3/27/2021, 12:48:38 AM] [] 286: } [Logs] [3/27/2021, 12:48:38 AM] [] 287: [Logs] [3/27/2021, 12:48:38 AM] [] 288: bool try_lock(const std::string& op = "UNKNOWN") { [Logs] [3/27/2021, 12:48:38 AM] [] #3 Object "/usr/lib/aarch64-linux-gnu/libstdc++.so.6.0.25, at 0x7fb2d57f67, in cxa_throw [Logs] [3/27/2021, 12:48:38 AM] [] #2 Object "/usr/lib/aarch64-linux-gnu/libstdc++.so.6.0.25, at 0x7fb2d57c9f, in std::terminate() [Logs] [3/27/2021, 12:48:38 AM] [] #1 Object "/usr/lib/aarch64-linux-gnu/libstdc++.so.6.0.25, at 0x7fb2d57c53, in [Logs] [3/27/2021, 12:48:38 AM] [] #0 Source "/kismet/kismet_server.cc", line 301, in TerminationHandler [Logs] [3/27/2021, 12:48:38 AM] [] 299: #ifndef DISABLE_BACKWARD [Logs] [3/27/2021, 12:48:38 AM] [] 300: using namespace backward; [Logs] [3/27/2021, 12:48:38 AM] [] > 301: StackTrace st; st.load_here(32); [Logs] [3/27/2021, 12:48:38 AM] [] 302: Printer p; p.print(st); [Logs] [3/27/2021, 12:48:38 AM] [] 303: #endif [Logs] [3/27/2021, 12:48:38 AM] [] Uncaught exception "std::exception"