Unauthenticated Pairing - BlueZ to nrf52832

RE: Unauthenticated Pairing - BlueZ to nrf52832

ovrebekk — Mon, 05 Feb 2024 09:02:25 GMT

Great to hear that you were able to figure it out, I will close the ticket then 🙂

RE: Unauthenticated Pairing - BlueZ to nrf52832

Ibrahim_Augury — Sun, 04 Feb 2024 14:05:22 GMT

Ok So I solved the problem with erasing the external memory where i saved the keys of the encryption and settings also I run this command in my terminal : unblock <mac_address>
This two things solved my problem
Thanks a lot for the help

RE: Unauthenticated Pairing - BlueZ to nrf52832

ovrebekk — Tue, 30 Jan 2024 08:31:03 GMT

Hi Ibrahim

Did you try to perform a full chip erase like I asked?

In order to investigate further I think we need a sniffer trace, the log messages are all very generic and don't include much details about what is failing.

Can you follow the link I shared earlier and get the sniffer running, and capture a trace showing the connection establishment and the authentication failure?
Then you can save the trace to file in Wireshark and attach the trace to this case.

Best regards
Torbjørn

RE: Unauthenticated Pairing - BlueZ to nrf52832

Ibrahim_Augury — Mon, 29 Jan 2024 06:28:07 GMT

Debug output in the nrf52832 its a customize chip we built
Bluetooth advertising start!
I: Connected, MTU=23
I: Bluetooth advertising scheme reset (scheme will be restated)
I: Bluetooth advertising stopped
I: ConnInfo: type=1, role=1, id=0, interval=36
I: bt_conn_le_param_update success
I: le_data_len_updated: MTU 252 tx_max_len 251 tx_max_time 2120 rx_max_len 251 rx_max_time 2120
I: Delete 28:DF:EB:6A:35:5A (public) (keys 0x0000)
I: con_event log: naks 7, crc ok 0, crc err 0,timeouts 0, events 6, Rssi 0
I: Disconnected (reason 0x05)

This is my hci0 adapter info :
hci0: Type: Primary Bus: USB
BD Address: 28:DF:EB:6A:35:5A ACL MTU: 1021:4 SCO MTU: 96:6
UP RUNNING PSCAN ISCAN

RE: Unauthenticated Pairing - BlueZ to nrf52832

ovrebekk — Thu, 25 Jan 2024 12:36:46 GMT

Hi Ibrahim

Are you using a standard nRF52DK, or some other hardware?

Is there any chance that there is some old pairing data in the nRF52 device that is causing issues when you try to pair with your Linux host?

If you perform an erase all on your nRF52 device before programming the application will the same problem still occur?

Are you able to view the log output from the nRF52 device in order to see if it provides some more useful information?

If all else fails you might want to capture a sniffer trace of the exchange, using either a professional Bluetooth sniffer or the free one we provide: nRF Sniffer

Best regards
Torbjørn