Abnormal behavior in Bluetooth-dense environments

[JosephHewitt]

"Side B" will stop sending the "BLE," (Bluetooth device count) messages to "side A" in Bluetooth dense areas. I observed this happening when the device count was in the region of 145 - 165 or higher. Other data (GSM) was still sent normally from side B.

I haven't yet checked the logs or collected data to determine if this issue causes data loss.

This issue manifests as a stuck BLE counter on the LCD. Rebooting the wardriver will cause the "ESP-B NO DATA" warning as this warning is triggered by a lack of "BLE," messages on boot. Moving away from the Bluetooth-dense area fixes this issue.

[pejacoby]

I saw this issue today while walking through a very BlueTooth heavy environment. The wardriver was in my bag so I didn't observe the display, but after the run I can see a large gap in BT data in the heavily congested area. My drive to the location shows plenty of BT, but as some point and during the walk in the high-density area there is no BT from the wardriver. I picked up lots of BT on my other three phones running WigleWiFi. Once I left the high-density area, the data shows BlueTooth recording resumed.

Sorry I don't have much more than that to offer, though I can provide the data file it it's of any use.

[JosephHewitt]

Thanks for the information. It seems like the wardriver is simply being overwhelmed with the amount of Bluetooth data and then stops reporting information temporarily.

I still need to find a way to reliably reproduce this since going to crowded locations to debug isn't very viable. I don't think the data file will offer any insights but thank you for the offer.

[JosephHewitt]

I have confirmed this is a crashing issue, possibly related to #77

I was able to capture the output during a crash when running from main 1.2.1:

E (35922) task_wdt: Task watchdog got triggered. The following tasks/users did not reset the watchdog in time:
E (35922) task_wdt:  - IDLE0 (CPU 0)
E (35922) task_wdt: Tasks currently running:
E (35922) task_wdt: CPU 0: BTC_TASK
E (35922) task_wdt: CPU 1: IDLE1
E (35922) task_wdt: Aborting.
E (35922) task_wdt: Print CPU 0 (current core) backtrace




Backtrace: 0x400e9d26:0x3ffe2c80 0x401a3255:0x3ffe2cc0 0x400e10f6:0x3ffe2d40 0x400dc6b1:0x3ffe2de0 0x401272b1:0x3ffe2e40 0x4012777d:0x3ffe2e60 0x40157569:0x3ffe2e80 0x40157505:0x3ffe2ea0 0x4009745e:0x3ffe2ed0




ELF file SHA256: 6c9e4432176d02c5

Rebooting...
ets Jun  8 2016 00:22:57

rst:0xc (SW_CPU_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:1
load:0x3fff0030,len:4832
load:0x40078000,len:16460
load:0x40080400,len:4
load:0x40080404,len:3504

Decoded:

    0x400e9d26: uart_ll_is_tx_idle at /home/joseph/Documents/projects/compile_wardriver/builder/packages/esp32/tools/esp32-arduino-libs/idf-release_v5.1-33fbade6/esp32/include/hal/esp32/include/hal/uart_ll.h:771
    0x400e9d26: log_printfv at /home/joseph/Documents/projects/compile_wardriver/builder/packages/esp32/hardware/esp32/3.0.5/cores/esp32/esp32-hal-uart.c:921
    0x401a3255: __wrap_log_printf at /home/runner/work/esp32-arduino-lib-builder/esp32-arduino-lib-builder/managed_components/espressif__esp_diagnostics/src/esp_diagnostics_log_hook.c:418
    0x400e10f6: BLEUtils::dumpGapEvent(esp_gap_ble_cb_event_t, esp_ble_gap_cb_param_t*) at /home/joseph/Documents/projects/compile_wardriver/builder/packages/esp32/hardware/esp32/3.0.5/libraries/BLE/src/BLEUtils.cpp:1102
    0x400dc6b1: BLEDevice::gapEventHandler(esp_gap_ble_cb_event_t, esp_ble_gap_cb_param_t*) at /home/joseph/Documents/projects/compile_wardriver/builder/packages/esp32/hardware/esp32/3.0.5/libraries/BLE/src/BLEDevice.cpp:173
    0x4009745e: vPortTaskWrapper at /home/runner/work/esp32-arduino-lib-builder/esp32-arduino-lib-builder/esp-idf/components/freertos/FreeRTOS-Kernel/portable/xtensa/port.c:162