This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

CC2540: BLE Captures with Packet Sniffer using CC2540

Part Number: CC2540
Other Parts Discussed in Thread: CC2650, CC2560

Hi all,

I have created two environments to testing BLE. For each environment was sniffed the traffic with CC2540 connected to Packet Sniffer. The results is absolutely different for each environment.

It is clear that the difference between the gateways is the problem because Sensortag cc2650 is used in both cases to generate data. My questions are:

  1. Why there are so many differences in the captues if both implement BLE and using the same CC2650?
  2. In both captures, the Connect Request screen appears, in addition to Features Request and Features Respone. Why the dongle connected to the beaglebone does not send more frames
  3. In the case of the APP, the LTK is recovered. I have done the same test with Ubertooth and it also recovers the LTK but it is encrypted. However, there are ways to find it. Why in one case the LTK is recovered and in the other, even the exchange of the randoms?
  1. Dongle connected to Beaglebone and sensortag cc2560 transmiting BLE (figure shows the interaction). 

  1. CC2560 Sensortag conected to App android (based on: https://github.com/googlesamples/android-BluetoothLeGatt)

Best,

Santiago

  • Hi Santiago,

    1. BLE is a very flexible protocol, based on timing and other parameters even multiple connections between the same two devices may look differently. In general it seems that the major difference between #1 and #2 is that in #1 the dongle will not initiate pairing with the sensortag but instead performs GATT discovery first. In #2 the phone is first initiating pairing and encryption.

    2. Some devices perform GATT disovery and pairing autonomously on connect. However, after that they will simply maintain the connection. Maintaining the connection requires sending empty data packets such as #118 in case #2 or #672 in case #1. These packets are responsible for maintaining the link. If you want to send further application data between the device you will need to manually trigger this (sending commands in the app, etc)

    3. I can't comment on the ubertooth technology, but there are some pairing procedures that cannot be sniffed for the LTK such as LE Secure Connections pairing with MITM. It depends on whether the pairing procedure sends the key in plaintext or if any packets are missed during pairing by the sniffer.
  • Thanks , i appreciated your answer.

    Best,

    Santiago