Regarding the behavior of pairing

[tommy]

In the pairing process among 1 Central and 2 Peripherals

Sometimes the Pairing  processing rarely does not work correctly and the following log output:

<err> cis_gateway: ACL connection to 4B:01:AA:9F:C4:2F (random) failed, error 2

 

Please find the attached ppt.

Would it be pssilbe to let us know what cause this problem?

We could confirm this in SDK2.3.0 and improved in SDK2.7.0.

Pairing err.pptx

BR,

[Edvin]

Hello,

Please provide logs either in .txt files or insert->code here in DevZone in the future.

So your connected callback has err = 2 = BT_HCI_ERR_UNKNOWN_CONN_ID. 

From the description of the connected callback, it says:

	 *  @p err can mean either of the following:
	 *  - @ref BT_HCI_ERR_UNKNOWN_CONN_ID Creating the connection started by
	 *    @ref bt_conn_le_create was canceled either by the user through
	 *    @ref bt_conn_disconnect or by the timeout in the host through
	 *    @ref bt_conn_le_create_param timeout parameter, which defaults to
	 *    @kconfig{CONFIG_BT_CREATE_CONN_TIMEOUT} seconds.

Do you see anything in the log of the device you are trying to connect to?

Is the address in the log of the GW the one that you expect it to be? Or is it trying to connect to something else?

Best regards,

Edvin

[tommy]

Thank you for your reply.

 

Do you see anything in the log of the device you are trying to connect to?
⇒The Log shown in <headset_L> of the Failure Log shown previously is output.

 

Is the address in the log of the GW the one that you expect it to be? Or is it trying to connect to something else?
⇒This is the expected one.

[tommy]

It could be that the peripheral didn't pick up the connection request packet. Can you please try to capture a sniffer trace of the error?
⇒I captured the success and failure scenarios using Sniffer.
　I will send the capture data at that time along with the addresses of the target devices.
　(In the case of failure, the headsetL side failed to pair.)

SDK2.3.0_failed_addr

headsetL:62:06:2F:50:47:1A
headsetR:5E:E3:96:69:BB:97

SDK2.3.0_success_addr

headsetL:6B:F7:16:1D:67:5C
headsetR:73:34:84:61:DF:B6

SDK2.3.0_failed.pcapngSDK2.3.0_success.pcapng

[Edvin]

Hello,

Please select the advertising device in this drop-down-menu

Then the sniffer will only show relevant packets for that advertising device, as well as follow the devices into a connection. Without selecting that, I can't see what happens after the CONNECT_IND packet, whether the peripheral picked it up or not.

Please note that I will be out of office until January 2nd (and so will most of my colleagues). So please expect some extra latency in our replies. I am sorry for the inconvenience.

Best regards,

Edvin

[tommy]

Even if I start from advertising, the target device address does not appear in the advertising device section. 
Even when I set it to Add LE address and input the target address in the Value field, it does not display.

(inputting it as 77:86:19:75:72:68 random)

 

My question is: I am currently using the nrf5340Audio project with SDK 2.3.0 for verification. 
Is my understanding correct that the address to be entered in Add LE address is the one output in the log as shown below? 
GW [00:00:21.364,410] cis_gateway: Connected: 77:86:19:75:72:68 (random)

[Edvin]

The order of bytes in a BLE address are shown varies a lot. My first attempt would be to flip the address around in your address filter:

68:72:75:19:86:77

And see if it pops up. 

Best regards,

Edvin

[Edvin]

If it does not, then program it with a sample that you know is working as it should, and then look for it in the sniffer. Look at the way that the address is represented there. 

BR,
Edvin