• State Verified Answer
  • Replies 11 replies
  • Subscribers 63 subscribers
  • Views 6372 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 111687
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

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?

  • 0

    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.

  • 0 in reply to run_ar

    Thank you for your answer run_ar. I just tried reinstalling the latest version of the UART drivers but unfortunately the behavior remained the same afterwards.

    What is strange is that when the sniffing stops after the LL_CHANNEL_MAP_REQ, I can make it resume without touching the ble-sniffer_win program or Wireshark, just by turning off the Android phone that was connected to the device. When I do that, I see again the ADV_INDs from the master, and when I pair the devices once more I can see all the communication again. And this will last once more for ~1h30min then it stops again after a LL_CHANNEL_MAP_REQ.

    Leads me to think that UART, ble-Sniffer and Wireshark are all fine, but could it be that under certain circumstances the LL_CHANNEL_MAP_REQ is not handled properly by the sniffer's firmware and it gets lost?

  • 0 in reply to run_ar

    what is the connection interval of the link? I have a vague suspicion that it is related to the connection event counter of the sniffer that it is not able to handle the wrapping of the 16 bit counter

  • 0 in reply to run_ar

    My connection parameters are: Min interval = 100 msec, max interval = 150 msec. I have noticed in the log that sometimes a counter overflows:

    02-Feb-2016 12:27:58 INFO: gap in packets, between 65535 and 0 (...)
02-Feb-2016 13:41:08 INFO: UART read timeout (2 seconds).
02-Feb-2016 13:41:10 INFO: UART read timeout (2 seconds).

    Or still:

    03-Feb-2016 19:00:30 INFO: gap in packets, between 65535 and 0 packet before: (...)
03-Feb-2016 19:29:59 (Europe de l’Ouest) INFO: UART read timeout (2 seconds).

    But more often than not, the sniffer stops long after this event (30 minutes, 1 hour,...). Is this the 16 bit counter you meant?

  • 0 in reply to run_ar

    Yes, it is that counter I mean, is that the first channel map update/LL control procedure after that wraparound? or has that been done earlier?

Related