• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 51 subscribers
  • Views 630 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

CC2564: Passkey display

Manoj Chandran
Intellectual 260 points
Part Number: CC2564

Hi,

We are using SPP profile for Ti Bluetooth Stack in our design. Our device is configured as server and the IOcapability is set as icDisplayOnly. Our device is having a display. When try to pair through mobile phone, the passkey is directly send to the mobile phone. Our requirement is to display the passkey in the display and the mobile phone user has to type the passkey in  his mobile phone. Please advise how I can configure the device so that the it won't send the passkey directly to the client.

Regards

Manu.

  • 0
    TI__Mastermind 29250 points
    Hi Manoj,

    I will try to replicate this by changing the IOcapability in the default SPPDemo. Did you make any other change to the SPP Sample Application that I should be aware of?

    Best regards,
    Vihang
  • 0 in reply to Vihang Parmar
    Intellectual 260 points

    Hi Vihang,

    Thank you very much for the immediate response. 

    I have made DEFAULT_MITM_PROTECTION to true and at atPasskeyNotification switch case we have added our own callback function to display the passkey in our display. In the setpairable function we are setting mode as pmPairableMode_EnableSecureSimplePairing.

    Regards,

    Manoj

  • 0 in reply to Manoj Chandran
    TI__Mastermind 29250 points

    Hi Manoj,

    Please refer to the Table 5.7 : OP Capability Mapping to Authentication Stage 1 of Bluetooth Specification [Vol 3, Part C].

    For your setup : 

    1. The mobile device is the Initiator
    2. The SPPDemo is the responder

    According to the Bluetooth specifications, if the responder's IO capabilities are "Display Only", the responder will use Numerica Comparision with automatic confirmation in all cases; except when the initiator's IO capabilities are "Keyboard Only". Most phones (i.e. Android) have IO capabilities set to "Display Only". Thus, the phone's pairing with your setup will always yield to automatic confirmation unless you can change the phone's IO capabilities to "Keyboard Only".

    So the devices are behaving according to the Bluetooth specification by choosing automatic confirmation. If you think about it, this arrangement makes sense. The purpose of the IO capabilities in the Secure Simple Pairing is to determine which form of authentication (by a person) should be used. Now if the responder device only has a display without any input, displaying a number on the responder will not serve any purpose when it comes to authentication. If the responder cannot respond with either Yes/No or a user input, there is no authentication. 

    Best regards,

    Vihang

  • 0 in reply to Vihang Parmar
    Intellectual 260 points

    Hi Vihang,

    Thank you.

    Manoj

  • 0 in reply to Manoj Chandran
    Intellectual 260 points

    Hi Vihang,

    Hope you are doing fine.

    We have a change of requirement. Now we need to reject pairing requests from devices with IO capability other than 'Keyboard only'. Is there any way by which we can get the IO capability of the initiator from the responder's stack.

    Regards,
    Manoj