S120 Multilink Central app connects, then very quickly disconnects (Reason: BLE_HCI_CONN_FAILED_TO_BE_ESTABLISHED)

[mtsunstrum]

I have taken the S120 app, and am trying to have it connect to an external peripheral (not the provided S120 Multilink Peripheral app)

The S120 app successfully discovers the peripheral's advertising, and proceeds to establish a connection, and perform service discovery.

But very quickly, the S120 receives a connection disconnect event, with reason code BLE_HCI_CONN_FAILED_TO_BE_ESTABLISHED.

Application Log is as follows:

[APPL]:[0x00] >> DM_EVT_CONNECTION
	[APPL]:[BA 49 B1 EB D7 90]: Connection Established

	[APPL]:[CI 0x00]: Requesting GATT client create
	[DB]: Starting discovery of service with UUID 0xffe0 for Connection handle 0
[APPL]:[0x00] << DM_EVT_CONNECTION

[APPL]:[0x00] >> DM_EVT_DISCONNECTION
[APPL]:[0x00] << DM_EVT_DISCONNECTION

No service discovery activites appear to happen because of the immediate disconnect.

At moment of disconnect, I captured the p_event data structure ...

p_event 0x20003f44 event_id 18 event_param {...} p_gap_param 0x20002e48 conn_handle 0 params {...} connected {...} peer_addr {...} addr_type 0x3e addr 0x20002e4b addr[0] 0xba addr[1] 0x49 addr[2] 0xb1 addr[3] 0xeb addr[4] 0xd7 addr[5] 0x90 irk_match 0 irk_match_idx 0 conn_params {...} min_conn_interval 48 max_conn_interval 48 slave_latency 0 conn_sup_timeout 400 disconnected {...} reason 0x3e conn_param_update {...} sec_params_request {...} sec_info_request {...} passkey_display {...} auth_key_request {...} auth_status {...} conn_sec_update {...} timeout {...} rssi_changed {...} adv_report {...} sec_request {...} conn_param_update_request {...}

What is not clear to me is what would cause it to reject a connection request. With my peripheral unit, I am able to connect to it perfectly fine with a tool such as BlueGiga's BLEGUI app.

Any help is appreciated.

[vich]

Hi mtsunstrum,

I have taken a look at your trace. On first glance, it appears that the peer did not receive/listen to the CONNECT_REQ (evident from your application log, as the application found the peer second time before disconnection from the first attempt).

In addition to version information of SD, could you please reproduce the issue while capturing a trace with BLE Sniffer release 0.9.6. Use the 's' option and upload all files from the sniffer's logs folder(capture.pcap, log.txt etc..)

Thanks.

[mtsunstrum]

Answer to a couple of questions:

Can you reproduce the issue consistently ? Yes, I can. In 95% of the times, I will receive the BLE_HCI_CONN_FAILED_TO_BE_ESTABLISHED termination. There have been two times I have seen in the logs where the connection actually did get established.

S120 Softdevice Version: 1.0.0-1.alpha

I am using BLE Sniffer 0.9.6_BETA_812. I ran with -s option, but I do not see any "logs" folder in my Sniffer directory. But the Wireshark capture is the same as the previous capture.

[mtsunstrum]

Commenting on

I have taken a look at your trace. On first glance, it appears that the peer did not receive/listen to the CONNECT_REQ (evident from your application log, as the application found the peer second time before disconnection from the first attempt).

On the second time, it found the peer (peripheral) advertising packet, but also, this second attempt failed to establish a connection with same reason code BLE_HCI_CONN_FAILED_TO_BE_ESTABLISHED.

Thanks

[mtsunstrum]

One think I noticed different in the CONNECT_REQ packets ... See packet header field in Wireshark trace

S120 Central:     
    TX address flag = random, RX address flag = public
BLEGUI Central: 
    TX address flag = public, RX address flag = public

I am not immediately familiar with what difference this may cause. Any thoughts on this being a reason for the Peripheral to not respond ?

Thx

[vich]

This is not a problem, S120 Central uses a random static address whereas the peripheral is using public address. Hence, the connect_req contains the tx address type as random for the Init Address.