Real-time wiglecsv logger does not process BTLE packets from hardware sniffers

[PoppaShell]

Disclosure: This issue was discovered, diagnosed, and drafted with assistance from Claude (Anthropic) while working on the WarPie wardriving project.

Summary

The real-time wiglecsv logger (kis_wiglecsvlogfile.cc) registers handlers for IEEE802.11, Bluetooth, and BTLE PHY types, but the packet_handler does not actually process BTLE packets from hardware sniffers. When using wardrive mode with a CC2540/Ubertooth/nRF, the .wiglecsv file contains WiFi networks but zero Bluetooth/BTLE devices.

Environment

• Kismet version: 2025.09.0-b5d5a2d04
• Hardware: Raspberry Pi 4B + TI CC2540 USB dongle
• OS: Raspberry Pi OS (Debian Bookworm)
• Mode: kismet --override wardrive
• GPS: gpsd with USB GPS receiver (confirmed working)

Steps to Reproduce

1. Start Kismet in wardrive mode with CC2540:

   kismet -t test --override wardrive -c wlan1 -c ticc2540-0

2. Drive/walk to capture WiFi and BTLE devices

3. Check the real-time wiglecsv output:

   cut -d',' -f11 Kismet-*.wiglecsv | sort | uniq -c

4. Check the kismetdb for comparison:

   sqlite3 Kismet-*.kismet "SELECT phyname, COUNT(*) FROM packets WHERE lat != 0 GROUP BY phyname;"

Expected Behavior

The .wiglecsv file should contain both WiFi (Type=WIFI) and BTLE (Type=BLE) records, matching what's captured in the kismetdb.

Actual Behavior

• wiglecsv file: Contains only WiFi records
• kismetdb: Contains both WiFi AND BTLE packets with GPS

# From kismetdb (data IS captured):
BTLE|30154 packets with GPS
IEEE802.11|7365 packets with GPS

# From wiglecsv (BTLE missing):
WIFI|2492 records
BLE|0 records

Code Analysis

In kis_wiglecsvlogfile.cc, the constructor fetches PHY handlers:

dot11_phy = static_cast(devicetracker->fetch_phy_handler_by_name("IEEE802.11"));
bt_phy = static_cast(devicetracker->fetch_phy_handler_by_name("Bluetooth"));
btle_phy = static_cast(devicetracker->fetch_phy_handler_by_name("BTLE"));

if (dot11_phy == nullptr || bt_phy == nullptr || btle_phy == nullptr) {
    _MSG_FATAL("Could not initialize wigle log, phys not available");
    // ...
}

The PHY handlers are registered, suggesting BTLE support was intended. However, the packet_handler function appears to only process packets that match certain criteria, and BTLE packets from hardware sniffers don't trigger the logging path.

Hypothesis

The packet_handler was likely designed with HCI Bluetooth scanning in mind (which doesn't generate packets, only device discovery events). Hardware sniffers like CC2540 generate actual BTLE advertisement packets, which follow a different code path that bypasses the wiglecsv logging.

Related Issues

• Kismet not recording Bluetooth devices in wiglecsv logs #514 - HCI Bluetooth not having GPS in data table
• kismetdb_to_wiglecsv ignores BTLE packets from hardware sniffers (CC2540, Ubertooth, nRF) #583 - kismetdb_to_wiglecsv converter has the same gap (same root cause, different code path)

Impact

Users running wardrive mode with BTLE hardware sniffers (CC2540, Ubertooth One, nRF51822, nRF52840) cannot upload Bluetooth data to WiGLE using the built-in tools, despite the data being captured correctly.

Workaround

1. Use regular Kismet mode (not wardrive) to ensure kismetdb logging
2. Use a custom Python script to extract BTLE from the kismetdb packets table
3. Generate WiGLE CSV manually with correct Type=BLE field

Documentation Note

The Wardrive Mode documentation states:

"Kismet can now export directly to Wigle compatible CSV logs. These contain access points and bluetooth devices."

This implies Bluetooth support that doesn't currently function for hardware sniffer captures.

[dragorn]

This is currently expected behavior.

…

-------- Original Message --------

On Tuesday, 12/30/25 at 21:25 S̀͆̚h͂ͬ͆̇̋̍̒e͐ͬͤ͑͂ͯ̌lͦdo̓̄̆n̄̋ͦ̍ͦ̏ ***@***.***> wrote: PoppaShell created an issue [(kismetwireless/kismet#584)](#584) > Disclosure: This issue was discovered, diagnosed, and drafted with assistance from Claude (Anthropic) while working on the [WarPie](https://github.com/PoppaShell/WarPie) wardriving project. Summary The real-time wiglecsv logger ([kis_wiglecsvlogfile.cc](http://kis_wiglecsvlogfile.cc/)) registers handlers for IEEE802.11, Bluetooth, and BTLE PHY types, but the packet_handler does not actually process BTLE packets from hardware sniffers. When using wardrive mode with a CC2540/Ubertooth/nRF, the .wiglecsv file contains WiFi networks but zero Bluetooth/BTLE devices. Environment - Kismet version: 2025.09.0-b5d5a2d04 - Hardware: Raspberry Pi 4B + TI CC2540 USB dongle - OS: Raspberry Pi OS (Debian Bookworm) - Mode: kismet --override wardrive - GPS: gpsd with USB GPS receiver (confirmed working) Steps to Reproduce - Start Kismet in wardrive mode with CC2540: kismet -t test --override wardrive -c wlan1 -c ticc2540-0 - Drive/walk to capture WiFi and BTLE devices - Check the real-time wiglecsv output: cut -d ' , ' -f11 Kismet- * .wiglecsv | sort | uniq -c - Check the kismetdb for comparison: sqlite3 Kismet- * .kismet " SELECT phyname, COUNT(*) FROM packets WHERE lat != 0 GROUP BY phyname; " Expected Behavior The .wiglecsv file should contain both WiFi (Type=WIFI) and BTLE (Type=BLE) records, matching what's captured in the kismetdb. Actual Behavior - wiglecsv file: Contains only WiFi records - kismetdb: Contains both WiFi AND BTLE packets with GPS # From kismetdb (data IS captured): BTLE|30154 packets with GPS IEEE802.11|7365 packets with GPS # From wiglecsv (BTLE missing): WIFI|2492 records BLE|0 records Code Analysis In [kis_wiglecsvlogfile.cc](http://kis_wiglecsvlogfile.cc/), the constructor fetches PHY handlers: dot11_phy = static_cast (devicetracker-> fetch_phy_handler_by_name ( " IEEE802.11 " )); bt_phy = static_cast (devicetracker-> fetch_phy_handler_by_name ( " Bluetooth " )); btle_phy = static_cast (devicetracker-> fetch_phy_handler_by_name ( " BTLE " )); if (dot11_phy == nullptr || bt_phy == nullptr || btle_phy == nullptr ) { _MSG_FATAL ( " Could not initialize wigle log, phys not available " ); // ... } The PHY handlers are registered, suggesting BTLE support was intended. However, the packet_handler function appears to only process packets that match certain criteria, and BTLE packets from hardware sniffers don't trigger the logging path. Hypothesis The packet_handler was likely designed with HCI Bluetooth scanning in mind (which doesn't generate packets, only device discovery events). Hardware sniffers like CC2540 generate actual BTLE advertisement packets, which follow a different code path that bypasses the wiglecsv logging. Related Issues - [#514](#514) - HCI Bluetooth not having GPS in data table - [#583](#583) - kismetdb_to_wiglecsv converter has the same gap (same root cause, different code path) Impact Users running wardrive mode with BTLE hardware sniffers (CC2540, Ubertooth One, nRF51822, nRF52840) cannot upload Bluetooth data to WiGLE using the built-in tools, despite the data being captured correctly. Workaround - Use regular Kismet mode (not wardrive) to ensure kismetdb logging - Use a custom Python script to extract BTLE from the kismetdb packets table - Generate WiGLE CSV manually with correct Type=BLE field Documentation Note The [Wardrive Mode documentation](https://www.kismetwireless.net/docs/readme/configuring/wardrive/) states: > "Kismet can now export directly to Wigle compatible CSV logs. These contain access points and bluetooth devices." This implies Bluetooth support that doesn't currently function for hardware sniffer captures. — Reply to this email directly, [view it on GitHub](#584), or [unsubscribe](https://github.com/notifications/unsubscribe-auth/AAZAOCFJNNGH7FKBGGVJL634EMX3JAVCNFSM6AAAAACQLQ6YVOVHI2DSMVQWIX3LMV43ASLTON2WKOZTG43TCOBRG4YTSMI). You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[PoppaShell]

Then what is the recommended method to run in a wardrive-like mode that captures both IEEE802.11 and BT/BTLE?