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.

BLE Authentication requirements not met

Other Parts Discussed in Thread: CC2540

I have a sensor with a TI stack and app installed on it. We buy this sensors from a manufacturer ready made, and we don't have any means of getting to FW itself. I'm developing a custom central with Nordic's stack. I can connect ti the sensor without any problem, but when I try to bond from my central to the sensor, I get a response from the sensor with an error code 0x83, which means "authentication requirements not met". I would like to know when is this response generated and what does it mean, because I don't have any knowledge about TI's stack? I can bond to the sensor with a smartphone, but not with my central. Can someone give me an answer on this topic?

Best regards,

Matic

  • Hello Matic,

    The SensorTag demo firmware is not built with LE Security (pairing) support enabled by default. I don't know what version of firmware you have since it wasn't specified in your post. You can check/update firmware using the respective SensorTag apps on iOS or Android.

    Since you receive the error on your central which is from Nordic, I suggest you follow up with Nordic as they will be in a better position to help you understand this error.

    Best wishes
  • once you need to check what is being used on Nordic application as an authentication method, just works or passkey or else ?
    After deleting the paired or/and bonded information first on the sensor product, when you try to pair with the product again from Nordic App, you would see a pairing request window, if just 'pair' or 'cancel', this means that 'just works', if a window to input a value, it indicates 'passkey' or else.
    If you can tell it, you can try to configure on your central code for it, respectively.

    Good luck.
    Ji Won

  • The remote sensor uses a static passkey as an authentication method. As I said, I don't have access to bonding info on the sensor, so I can't delete them. The sensor itself is an PIR sensor which uses a proprietary BLE module with CC2540 chip on it. It runs TI stack, and I can't make any changes to it. I can pair with the sensor using iPhone or Android phone, when it prompts me for a passkey. But I can't pair with my central, even if I implement static passkey exchange on it. My main question was about when does TI BLE stack return "Authentication requirements not met" error, what is the procedure for bonding with an passkey for TI stack? If I figure out why and when does this error occure, I can then modify my central's code to function that way.
  • Hi,

    I apologize, I initially thought you were referring to the SensorTag. I think the best option is to take a packet sniffer trace of the pairing sequence using a BLE air sniffer. The TI Packet Sniffer is one option.

    Also, a point of clarification, the "Authentication requirements not met" error is not coming from the TI BLE Stack, but your Central which is not TI based. It may be in response to a protocol exchange, but without the sniffer trace, I can't provide further guidance.

    Best wishes

  • Can the sniffer trace be done with wireshark? I'm attaching two traces, one is a pairing attempt with a windows phone, which succedes every time, and the other is pairing attempt with Nordic's central. I've asked some questions on Nordic's forum about this error, but they couldn't give me an answer. They said, it should work, but it doesn't, so I'm trying to get some info from you guys, so I could then try to figure out what is the source of the problem.

    Windows phone pairing: http://x.k00.fr/u6zmb
    Nordic's pairing attempt: http://x.k00.fr/4ifrw

  • Hi Matic,

    I'm unable to access your file links. Can you zip them up and attach to this post directly using the "Use rich formatting" option?

    Best wishes
  • Hi JXS, yesterday I figured out why this happens, it's because my central's name type is by default set to "random static". If I set it to "random private resolvable", it goes through the process of bonding without any problems. Therefore I call this case closed.

  • Hi Matic,

    Thanks for confirming. That does make sense and glad it's working on your end.

    Best wishes