Why does my BLE Sniffer stops after ~2h and a LL_CHANNEL_MAP_REQ?

[J_Bud]

Hello! I am using WireShark 1.12.1, nRF Sniffer software v1.0.1_1111 on Windows 7, and I am having an issue trying to run a long term capture.

I choose a device, it starts sniffing, I pair it and everything goes well for 1h30 to 2 hours, then it stops. The last request from the Master is always a LL_CHANNEL_MAP_REQ. Then the Slave responds with an Empty PDU and no more packs are captured. If I let it run still, sometimes a pack can be seen but it will always be a malformed pack, or one with bad CRC.

LL_CHANNEL_MAP_REQs also happen without stopping the sniffer, but the last request when it stops is always a LL_CHANNEL_MAP_REQ.

Meanwhile, the devices I was sniffing are still connected without issues. If I turn off the slave's bluetooth (it's an Android mobile phone), the sniffer will see ADV_INDs from the Master again, then I can proceed to pair once more and the sniffer will work happily again for another 1h30-2h.

The issue is that I need to run a longer capture (my goal is 48h), so I need to understand why the sniffer stops after ~2h and an LL_CHANNEL_MAP_REQ.

Sniffer log and the .pcap file are in this .zip file: BLECaptureStopped.zip

Any idea why this happens and if there is any way to make it run longer?

[run_ar]

Have you tried using the latest segger driver? There has been a long standing issue with the segger UART driver that would cause the UART to time out, this is supposedly fixed now.

[J_Bud]

Sorry for the delay in responding, I went through the logs and reproduced the behavior once more to confirm.

In two of my logs, it stopped on the first LL_CHANNEL_MAP_REQ after the wraparound as you suggested. In one of them, it seemed to continue after a few LL_CHANNEL_MAP_REQs after the wraparound, but I am not absolutely certain since I had some trouble matching the Wireshark file's timestamps and the log file timestamps.

In the last test I run I made a restart of the PC and plugged the sniffer just before starting the capture. There was no wraparound message in the log, and it stopped again after a LL_CHANNEL_MAP_REQ. Packet counter on wireshark was 37370. I know it is not the same as the sniffer's packet counter, but it should give a rough idea.