Disclosure: This issue was discovered, diagnosed, and drafted with assistance from Claude (Anthropic) while working on the WarPie wardriving project.
Summary
The kismetdb_to_wiglecsv converter tool does not export BTLE devices captured by hardware packet sniffers (TI CC2540, Ubertooth, nRF51822, nRF52840). These devices store packets in the packets table with phyname='BTLE', but the converter only queries for phyname='IEEE802.11'.
This is distinct from Issue #514 which addresses HCI Bluetooth scanning (which stores in the data table without GPS). Hardware sniffers store in the packets table WITH valid GPS coordinates, but the converter ignores them entirely.
Environment
- Kismet version: 2025.09.0-b5d5a2d04
- Hardware: Raspberry Pi 4B + TI CC2540 USB dongle
- OS: Raspberry Pi OS (Debian Bookworm)
- GPS: gpsd with USB GPS receiver (confirmed working)
Evidence
BTLE packets ARE being captured with GPS:
SELECT phyname, COUNT(*), SUM(CASE WHEN lat != 0 THEN 1 ELSE 0 END) as with_gps
FROM packets GROUP BY phyname;
BTLE|30154|30091 -- 99.8% have GPS coordinates ✅
IEEE802.11|7365|7365 -- 100% have GPS coordinates ✅
BTLE devices exist:
SELECT phyname, type, COUNT(*) FROM devices WHERE phyname = 'BTLE' GROUP BY type;
But WiGLE CSV output contains ZERO BTLE:
kismetdb_to_wiglecsv --in Kismet-*.kismet --out export.csv
cut -d',' -f11 export.csv | sort | uniq -c
17703 WIFI
0 BLE # ← Missing!
Root Cause Analysis
Looking at log_tools/kismetdb_to_wiglecsv.cc, the packets query only selects IEEE802.11.
The code iterates through packets but the device lookup and type assignment logic only handles:
IEEE802.11 from packets table → outputs as WIFIBluetooth/BTLE from data table → outputs as BT/BLE
The gap: BTLE packets from hardware sniffers go to the packets table (not data table), but with phyname='BTLE' instead of IEEE802.11. The converter never queries for this combination.
Three capture paths exist:
| Source |
Table |
PHY |
GPS |
Converter Handles? |
| WiFi adapters |
packets |
IEEE802.11 |
✅ |
✅ Yes |
| HCI Bluetooth |
data |
Bluetooth/BTLE |
❌ (#514) |
✅ Yes (when GPS exists) |
| Hardware sniffers |
packets |
BTLE |
✅ |
❌ No |
Suggested Fix
In kismetdb_to_wiglecsv.cc, extend the packets table processing to include BTLE:
// Current: Only processes IEEE802.11 from packets table
if (phy == "IEEE802.11") {
// ... existing WiFi handling
}
// Needed: Also process BTLE from packets table
if (phy == "BTLE") {
// Similar to Bluetooth handling but reading from packets table
// Output with Type=BLE
}The BTLE packets already have all required fields:
sourcemac - device MAC addresslat, lon, alt - GPS coordinatessignal - RSSIts_sec - timestamp
Workaround
Currently using a custom Python script to extract BTLE from the packets table directly:
cursor.execute("""
SELECT p.ts_sec, p.sourcemac, p.lat, p.lon, p.alt, p.signal
FROM packets p
WHERE p.phyname = 'BTLE' AND p.lat != 0
""")Related Issues
Additional Context
The TI CC2540 datasource is working correctly:
INFO: Detected new datasource ticc2540-1-3
INFO: BTLE capture running on channel 37
Packets are being stored with full metadata including GPS. The only missing piece is the export tool recognizing phyname='BTLE' in the packets table.
Summary
The
kismetdb_to_wiglecsvconverter tool does not export BTLE devices captured by hardware packet sniffers (TI CC2540, Ubertooth, nRF51822, nRF52840). These devices store packets in thepacketstable withphyname='BTLE', but the converter only queries forphyname='IEEE802.11'.This is distinct from Issue #514 which addresses HCI Bluetooth scanning (which stores in the
datatable without GPS). Hardware sniffers store in thepacketstable WITH valid GPS coordinates, but the converter ignores them entirely.Environment
Evidence
BTLE packets ARE being captured with GPS:
BTLE devices exist:
But WiGLE CSV output contains ZERO BTLE:
Root Cause Analysis
Looking at
log_tools/kismetdb_to_wiglecsv.cc, the packets query only selects IEEE802.11.The code iterates through packets but the device lookup and type assignment logic only handles:
IEEE802.11frompacketstable → outputs asWIFIBluetooth/BTLEfromdatatable → outputs asBT/BLEThe gap: BTLE packets from hardware sniffers go to the
packetstable (notdatatable), but withphyname='BTLE'instead ofIEEE802.11. The converter never queries for this combination.Three capture paths exist:
Suggested Fix
In
kismetdb_to_wiglecsv.cc, extend the packets table processing to include BTLE:The BTLE packets already have all required fields:
sourcemac- device MAC addresslat,lon,alt- GPS coordinatessignal- RSSIts_sec- timestampWorkaround
Currently using a custom Python script to extract BTLE from the packets table directly:
Related Issues
Additional Context
The TI CC2540 datasource is working correctly:
Packets are being stored with full metadata including GPS. The only missing piece is the export tool recognizing
phyname='BTLE'in the packets table.