• State
  • Locked Locked
  • Replies 8 replies
  • Subscribers 52 subscribers
  • Views 3539 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

CC2541: enable/disable pairing mode

Ophirti Bentalyi
Prodigy 130 points
Part Number: CC2541

Hi

I am a little confused regarding the parameters of 'GapBondMgr'. Or at least I think it is there.

My device is a peripheral device with no display. I do have a button. I am using SimpleBLEPeripheral as starting point.

My requirement is as follow:

1) In order to do new pairing, the user need to press the button first. Then the device should be visible and allows 'Just work' pairing. The device should allows Bonding.

2) If the user doesn't press the button, the device should allow connection from previously bonded central devices, but not allow new pairing.

I did the following definition:

uint32 passkey = 0; // passkey "000000"
uint8 pairMode = GAPBOND_PAIRING_MODE_WAIT_FOR_REQ;
uint8 mitm = FALSE;
uint8 ioCap = GAPBOND_IO_CAP_NO_INPUT_NO_OUTPUT;
uint8 bonding = TRUE;

new_adv_enabled_status=TRUE;
GAPRole_SetParameter(GAPROLE_ADVERT_ENABLED, sizeof( uint8 ), &new_adv_enabled_status );

This allows connections and paring.
I didn't find how to allow connection but disable new pairing

  • 0
    TI__Genius 11740 points
    Hi Ophirti,

    Sounds like you want to change the pairMode after you've successfully saved a bond - during a new connection establishment you'll have to use the GAPBondMgr_GetParameter api to get number of bonds. Then check that number to make sure it's greater than one and if the button is pressed. Then if so allow pairing, else use the GAPBondMgr_SetParameter to set pairing mode to GAPBOND_PAIRING_MODE_NO_PAIRING.

    Regards,
    Rebel
  • 0 in reply to A. Rebel
    Prodigy 130 points

    Thanks for the answer.

    I did as you suggested (setting GAPBOND_PAIRING_MODE_NO_PAIRING).
    And now, while pairing from my phone it works as expected

    (Pairing rejected while setting GAPBOND_PAIRING_MODE_NO_PAIRING and pairing allowed while setting GAPBOND_PAIRING_MODE_WAIT_FOR_REQ)

    BUT!

    Something very strange while I am using Windows (version 8.1).

    Pairing always works! No matter what's the setting.

    Thanks

  • 0 in reply to Ophirti Bentalyi
    TI__Genius 11740 points
    Hi Ophirti,

    That's good to hear!

    Interesting, can you provide a sniffer capture of the windows issue?

    It's possible that the windows machine requires encryption always, so it does a request. (which should have been declined, but a capture will reveal the full story)

    Regards,
    Rebel
  • 0 in reply to A. Rebel
    Prodigy 130 points

    Hi

    I did 2 captures with the exact same board and same firmware.
    I used TI "SmartRF Protocol Packet Sniffer"

    1) win81_pairing.psd - Showing the pairing process with Windows 8.1

    2) Android_Rejection.psd - Showing rejection in Android

    I didn't see an option to upload files in this forum, so I put a zip file in our company server.
    You can download the zip file with the 2 psd from the following link:

    www.megatone.com/.../BTCapture.zip

    Thanks!

  • 0 in reply to Ophirti Bentalyi
    TI__Genius 11740 points
    Took a quick look at both the captures - there's nothing but advertisement data in them.

    Try to recapture, or perhaps get a different sniffer (like a frontline or ellisys) and upload those.

    Regarding uploading to the forums, you need to click the 'Use rich formatting' button to access the enhanced posting screen. (Which will include the ability to upload files)

    Regards,
    Rebel
  • 0 in reply to A. Rebel
    Prodigy 130 points

    Hi

    I did lot's of debugging, And I think there is here a BIG security hole in the BLE stack. I suggest you check it very seriously.

    Here are my findings:

    I set GAPBOND_PAIRING_MODE_NO_PAIRING as follow:

    uint8 pairMode = GAPBOND_PAIRING_MODE_NO_PAIRING;
    GAPBondMgr_SetParameter( GAPBOND_PAIRING_MODE, sizeof ( uint8 ), &pairMode );

    The behavior of the BLE framework works as follow:

    In file gapbondmgr.c, function GAPBondMgr_ProcessGAPMsg
    the part that starts with:

       case GAP_PAIRING_REQ_EVENT:

    Everything works as expected. This part is being called as it should:

    VOID GAP_TerminateAuth( pPkt->connectionHandle, SMP_PAIRING_FAILED_NOT_SUPPORTED );

    And it never continue after that.

    ALL THIS DOESN'T MATTER IF CONNECTION IS DONE FROM WINDOWS 8.1!!!!!!
    Windows 8.1 just ignore the bonding part, and continue without bonding. And the BLE Framework accepts it and continue to response.

    If on the other hand, I try the connection from Android, there is no issue. Android do refuse to continue.

    In my humble opinion, there is here a security hole.

  • 0 in reply to Ophirti Bentalyi
    TI__Guru** 105180 points

    Hi,

    The behaviour you describe w.r.t Win 8.1 is consistent with the Bluetooth specification and not a "security hole in the BLE stack". In BLE, security is optional.  If you are concerned about security, I suggest configuring the relevant security permissions in your GATT table. This will prevent access to these characteristics if pairing/bonding has not completed.

    Best wishes

  • 0 in reply to JXS
    Prodigy 130 points

    Thank you for your answer.
    What is the right way to configure the BLE stack, in order to answer to the following requirements:

    1) Pairing is allowed only after pressing a button on the board
    2) Connection for paired devices always work.

    Right now I can't see any solution, if working with Windows 8.1.
    The solution you suggested, which is playing with 'security permissions' of the 'characteristics' is not good enough because of the following scenario:

    1) The user turn on the device and don't press the button. Hence the device is in 'GAPBOND_PAIRING_MODE_NO_PAIRING' mode.
    2) The user doesn't read my manual (since this what end users do), and do pairing from windows 8.1
    3) Pairing succeed.

    From now on, end user would never guess why he can't communicate with the device. From his point of view he did paring. But it is a false pairing. A paring that doesn't allow reading characteristics with security permission.