• State
  • Locked Locked
  • Replies 18 replies
  • Subscribers 53 subscribers
  • Views 1028 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.

CC2564C: Missing HCI_Simple_Pairing_Complete Event

Erik Almqvist
Prodigy 90 points
Part Number: CC2564C

Hi!

Our customer is utilizing the CC2564CC controller and experiences issues with a missing HCI_Simple_Pairing_Complete Event. Briefly, the use case is that the local device accepts the pairing request while the remote side rejects the pairing request. Two set of logs are attached with the same scenario.

In Logs_set1.rar:

* Missing event is between frame 49-50.

* There is a log from phone side we can see that pairing request was rejected on phone side (frame 539) and after that there was event HCI_Simple_Piaring_Complete with reason Authentication failure (frame 542). The same event should be generated by your BT controller according

In Logs_set2.rar:

* In the provided HCI log the event should be present between frame 50 – 51.

* This set of logs also contains firmware logs grabbed by customer.

It is our understanding that this event should always be generated, even in a disconnection scenario. This according to e.g. Version 5.2 | Vol 4, Part E  - 7.7.45.

"7.7.45 Simple Pairing Complete event
Description:
The HCI_Simple_Pairing_Complete event is used to indicate that the simple
pairing process has completed. A Host that is displaying a numeric value can
use this event to change its UI.
When the LMP simple pairing sequences fail for any reason, the
HCI_Simple_Pairing_Complete event shall be sent to the Host. When
HCI_Simple_Pairing_Complete event is sent in response to the IO capability
exchange failing, the Status parameter shall be set to the error code received
from the remote device. Otherwise, the Status shall be set to the error code
Authentication Failure (0x05)."

We'd like some clarification on these sequences. However, as we and the customers are working under NDA I am not keen on sharing the logs in the public forum. Hence, I've been recommended by your side to request a private channel for the exchange of further information.

Is this a known issue on your side?

Regards

  • 0
    TI__Mastermind 27080 points

    I will provide a box link to share the logs. In general, the controller would generate a 'HCI_Simple_Pairing_Complete_event' with error code (0x05), when the transaction timed out..

    Thanks

  • 0 in reply to Erik Almqvist
    TI__Mastermind 27080 points

    Do, you see 'HCI_Simple_pairing_complete_event', from the controller when the pairing was successful? I wonder, if t was missing in authentication failed cases, due to the remote tearing down the connection. 

    Which host and stack are being? We, can try to reproduce on our setup. Can, you please provide the steps.

    Thanks

  • 0 in reply to Hari Nagalla
    Prodigy 90 points

    I'm a bit tied to answer the question about reproduction steps as these are the logs we received from customer. They asked me to post the issue as my contact is out on vaccation for about a week. I do believe that the HCI_Simple_pairing_complete_event is received in case of pairing success, I do suspect this to be more of a corner case.

    These are the reproduction steps I was given were quite simple:

    "During the pairing procedure, local device accepts the pairing request and remote side rejects the pairing request. Then there is no indication of the failed pairing sent to application (due to the missing HCI_Simple_pairing_complete_event."

    The stack is our Cybercom stack.

  • 0 in reply to Erik Almqvist
    Intellectual 540 points

    Hi Hari Nagalla,

    This is Will from Garmin software. Any update on this issue?

    Thanks,

    Will

  • 0 in reply to Will Liao
    TI__Mastermind 27080 points

    Hi Will, Erik,

    I am not able to reproduce the issue on my setup with BluetopiaPM stack. My setup uses CC2564CQFNEVM plugged to the COM8 port of AM335x EVM with Linux environment. I will upload the complete logs to the box folder today. 

    I am using service pack1.4. Which service pack are you using? 

    Thanks

  • 0 in reply to Hari Nagalla
    Intellectual 540 points

    Hi,

    We are using service pack 1.3.

    Thanks,

    Will

  • 0 in reply to Will Liao
    Prodigy 90 points

    @Will - Can you add anything about the reproducability rate and steps for TI? 

    The uploaded logs doesn't really tell me anything besides that this is how it supposed to look, and it doesn't on our end.

  • 0 in reply to Hari Nagalla
    Prodigy 240 points

    Hi Hari Nagalla

        After both remote device and local device received the pairing numeric comparison request, then local device accept the request then remote device reject the numeric comparison request and then remote device disconnect the ACL link as quickly as possible.

       Using this steps, it's easy to reproduce such issue.

       I'm not sure the TI controller how to deal with such case, or you can disconnect the ACL link at the remote device firstly then reject the numeric comparison request? 

       Any way, from the core spec, you can know that the controller is the responsible for generate one pairing failed event to local host. So this is a problem for cc2564c chip.

      

  • 0 in reply to Jonathan Wang
    TI__Mastermind 27080 points

    Humm.. As per the specs, the remote side need to send the PDU 'LMP_Not_accepted' in the event of a mismatch/authentication failure. If it is instead tearing down the ACL link, then the controller would only report a 'Disconnection Event' as you are observing. The controller in this scenario can't determine if the Remote teared down the connection due to authentication failure of some other issue...  

    Thanks

  • 0 in reply to Hari Nagalla
    Intellectual 540 points

    Hi Erik,

    Any thought on this?

    Thanks,

    Will

  • 0 in reply to Will Liao
    Prodigy 90 points

    What part of the specification are you citing here? I think that the section "Version 5.2 | Vol 4, Part E 7.7.45 Simple Pairing Complete event" is quite clear?

    When the LMP simple pairing sequences fail for any reason, the
    HCI_Simple_Pairing_Complete event shall be sent to the Host.

  • 0 in reply to Hari Nagalla
    Prodigy 240 points

    Hi Hari Nagalla

        But from the core spec 5.2, you can find this:

    When the LMP simple pairing sequences fail for any reason, the
    HCI_Simple_Pairing_Complete event shall be sent to the Host.

       So any way, the controller should generate one event to notify the pairing procedure result?

  • 0 in reply to Jonathan Wang
    TI__Mastermind 27080 points

    I do not think this applies, when the Remote/Master sends a 'LMP_detach' with error code other then 'authentication failure'. If, you look at section 4.2.1.4, master is supposed to send 'LMP_detach' with error code, 'authentication failure', if is is detaching during secure authentication. But in your logs - It appears, peer device (master) is instead sending "Other end terminated connection" (0x13). So, controller is terminating the connection with this error code.

    Section : 4.2.1.4

    The slave shall verify that the
    SRES_master sent by the master matches the SRES_master calculated by the
    slave. If the response is not correct, then either device can end the connection
    by sending an LMP_detach PDU with the error code Authentication Failure
    (0x05) (see Section 4.1.2).

    Thanks

  • 0 in reply to Hari Nagalla
    Prodigy 90 points

    This part of the specification do cover the contract between the two controllers on the LMP layer, not between the controller and the host. The section regarding host controller interface that I cited clearly says that you should generate this event in any case - regardless of LMP error codes. All other controllers we've seen do this and our stack do expect this event in this scenario. 

    Regards

  • 0 in reply to Hari Nagalla
    Intellectual 540 points

    Hi Hari Nagalla,

    Please answer Erik's comment. Thanks.

  • 0 in reply to Will Liao
    Prodigy 90 points

    Hi!

    To me, the wording "for any reason" is pretty clear in this case. If there is an ongoing pairing procedure, it shall be cancelled towards host regardless of error reason.

    Would it help if we provided an airlog of the scenario?

    Regards

  • 0 in reply to Erik Almqvist
    TI__Mastermind 27080 points

    Hi,

    Yes, taking the airlogs would confirm the LMP error reason. 

    Anyways, I tried on a Ubuntu desktop machine with a USB dongle to create this scenario. It appears the USB dongle is using CSR chip. As, a peer device i used CC2564C with a Linux host, so that I can terminate the ACL connection during the pairing process. Pairing was initiated from the Ubuntu Bluez stack, and during the pairing the connection was disconnected from the peer. And, in this case too, Bluez logger (BTMON reported the 'SimplePairing Complete Event' with error code 'RemoteUserTerminateConnection' (0x13) from the USB BT dongle controller. IMO, it is probably easier to extend the pairing state machine in the Host Bluetooth stack to receive the 'RemoteUserTerminatedConnection' error code, treat it as authentication failed and connection is also terminated from remote. It can transition to connection resource cleanup and to init state? 

    hari@hari-Latitude-E6430:~$ hciconfig
    hci0: Type: Primary  Bus: USB
    BD Address: 00:1B:DC:F2:1F:05  ACL MTU: 310:10  SCO MTU: 64:8
    UP RUNNING PSCAN ISCAN
    RX bytes:759 acl:0 sco:0 events:58 errors:0
    TX bytes:3695 acl:0 sco:0 commands:57 errors:0

    > HCI Event: IO Capability Response (0x32) plen 9                                            #247 [hci0] 656.745046
            Address: 88:C2:55:D1:D5:6F (Texas Instruments)
            IO capability: DisplayYesNo (0x01)
            OOB data: Authentication data not present (0x00)
            Authentication: General Bonding - MITM required (0x05)
    > HCI Event: User Confirmation Request (0x33) plen 10                                        #248 [hci0] 656.816032
            Address: 88:C2:55:D1:D5:6F (Texas Instruments)
            Passkey: 418168
    @ MGMT Event: User Confirmation Request (0x000f) plen 12                                 {0x0003} [hci0] 656.816077
            BR/EDR Address: 88:C2:55:D1:D5:6F (Texas Instruments)
            Confirm hint: 0x00
            Value: 0x00066178
    @ MGMT Event: User Confirmation Request (0x000f) plen 12                                 {0x0002} [hci0] 656.816077
            BR/EDR Address: 88:C2:55:D1:D5:6F (Texas Instruments)
            Confirm hint: 0x00
            Value: 0x00066178
    @ MGMT Event: User Confirmation Request (0x000f) plen 12                                 {0x0001} [hci0] 656.816077
            BR/EDR Address: 88:C2:55:D1:D5:6F (Texas Instruments)
            Confirm hint: 0x00
            Value: 0x00066178
    > ACL Data RX: Handle 96 flags 0x02 dlen 10                                                  #249 [hci0] 659.649029
          L2CAP: Information Request (0x0a) ident 4 len 2
            Type: Extended features supported (0x0002)
    > ACL Data RX: Handle 96 flags 0x02 dlen 10                                                  #250 [hci0] 665.726293
          L2CAP: Information Request (0x0a) ident 4 len 2
            Type: Extended features supported (0x0002)
    > HCI Event: Simple Pairing Complete (0x36) plen 7                                           #251 [hci0] 671.800846
            Status: Remote User Terminated Connection (0x13)
            Address: 88:C2:55:D1:D5:6F (Texas Instruments)
    > HCI Event: Auth Complete (0x06) plen 3                                                     #252 [hci0] 671.801837
            Status: Remote User Terminated Connection (0x13)
            Handle: 96
    @ MGMT Event: Authentication Failed (0x0011) plen 8                                      {0x0003} [hci0] 671.801874
            BR/EDR Address: 88:C2:55:D1:D5:6F (Texas Instruments)
            Status: Disconnected (0x0e)
    @ MGMT Event: Authentication Failed (0x0011) plen 8                                      {0x0002} [hci0] 671.801874
            BR/EDR Address: 88:C2:55:D1:D5:6F (Texas Instruments)
            Status: Disconnected (0x0e)
    @ MGMT Event: Command Complete (0x0001) plen 10                                          {0x0001} [hci0] 671.801887
          Pair Device (0x0019) plen 7
            Status: Disconnected (0x0e)
            BR/EDR Address: 88:C2:55:D1:D5:6F (Texas Instruments)
    < HCI Command: Disconnect (0x01|0x0006) plen 3                                               #253 [hci0] 671.824549
            Handle: 96
            Reason: Remote User Terminated Connection (0x13)
    > HCI Event: Command Status (0x0f) plen 4                                                    #254 [hci0] 671.825851
          Disconnect (0x01|0x0006) ncmd 1
            Status: Success (0x00)
    > HCI Event: Disconnect Complete (0x05) plen 4                                               #255 [hci0] 671.951857
            Status: Success (0x00)
            Handle: 96
            Reason: Remote User Terminated Connection (0x13)
    @ MGMT Event: Device Disconnected (0x000c) plen 8                                        {0x0003} [hci0] 671.951918
            BR/EDR Address: 88:C2:55:D1:D5:6F (Texas Instruments)
            Reason: Connection terminated by remote host (0x03)

    IMO, it is probably easier for the state machine on the host to come out of the pairing state, even when it gets an error event other than, "Authentication Failure".