I am developing pairing feature in BlueZ application and encounter a problem which is related to this commit.
It seems to have timing issue between SMP distribution and command complete of HCI_OP_WRITE_AUTH_PAYLOAD_TO.
The symptom is, when pairing is proceeding, after remote peer (Peripheral ) sending the Encryption information and Identity information to local Host (BlueZ based Central).
The local host doesn’t move forward to send out the Encryption information and Identity information and pairing procedure is not completed.
From btmon log, there is no “MGMT Event: New Long Term Key (0x000a)” event shows and no LTK created in /var/lib/Bluetooth/
From syslog, there are some SMP commands from ACL are drop as following log snippet.
“Bluetooth: hci0: unexpected SMP command 0x06 from 34:81:f4:ae:0e:b1
Bluetooth: hci0: unexpected SMP command 0x07 from 34:81:f4:ae:0e:b1
Bluetooth: hci0: unexpected SMP command 0x08 from 34:81:f4:ae:0e:b1”
I dig into the SMP part in Linux kernel and found SMP protocol procedure are guarded by allow_cmd flag and SMP_ALLOW_CMD marco to make sure the SMP PDU are received in correct order.
In Our observation, SMP_ALLOW_CMD(SMP_CMD_ENCRYPT_INFO) will be called after command complete of HCI_OP_WRITE_AUTH_PAYLOAD_TO received.
I think BlueZ expect SMP_CMD_ENCRYPT_INFO, SMP_CMD_INITIATOR_IDENT SMP_CMD_IDENT_INFO PDU comes after HCI_OP_WRITE_AUTH_PAYLOAD_TO were complete.
When this command complete event comes later then SMP_CMD_ENCRYPT_INFO, SMP_CMD_INITIATOR_IDENT and SMP_CMD_IDENT_INFO.
smp_sig_channel() rejects the handle of PDU SMP_CMD_ENCRYPT_INFO (0x06), and so the following PDU 0x07, 0x08.
However, these SMP packets and HCI command/event should be independent and can’t guarantee the sequence, it might cause problems.
Please reference following air sniffer log and HCI UART traffic capture. Btmon and Linux syslog related are attached as well.
I am developing pairing feature in BlueZ application and encounter a problem which is related to this commit.
It seems to have timing issue between SMP distribution and command complete of HCI_OP_WRITE_AUTH_PAYLOAD_TO.
The symptom is, when pairing is proceeding, after remote peer (Peripheral ) sending the Encryption information and Identity information to local Host (BlueZ based Central). The local host doesn’t move forward to send out the Encryption information and Identity information and pairing procedure is not completed.
From btmon log, there is no “MGMT Event: New Long Term Key (0x000a)” event shows and no LTK created in /var/lib/Bluetooth/
From syslog, there are some SMP commands from ACL are drop as following log snippet.
“Bluetooth: hci0: unexpected SMP command 0x06 from 34:81:f4:ae:0e:b1
Bluetooth: hci0: unexpected SMP command 0x07 from 34:81:f4:ae:0e:b1
Bluetooth: hci0: unexpected SMP command 0x08 from 34:81:f4:ae:0e:b1”
I dig into the SMP part in Linux kernel and found SMP protocol procedure are guarded by allow_cmd flag and SMP_ALLOW_CMD marco to make sure the SMP PDU are received in correct order. In Our observation, SMP_ALLOW_CMD(SMP_CMD_ENCRYPT_INFO) will be called after command complete of HCI_OP_WRITE_AUTH_PAYLOAD_TO received. I think BlueZ expect SMP_CMD_ENCRYPT_INFO, SMP_CMD_INITIATOR_IDENT SMP_CMD_IDENT_INFO PDU comes after HCI_OP_WRITE_AUTH_PAYLOAD_TO were complete.
When this command complete event comes later then SMP_CMD_ENCRYPT_INFO, SMP_CMD_INITIATOR_IDENT and SMP_CMD_IDENT_INFO. smp_sig_channel() rejects the handle of PDU SMP_CMD_ENCRYPT_INFO (0x06), and so the following PDU 0x07, 0x08. However, these SMP packets and HCI command/event should be independent and can’t guarantee the sequence, it might cause problems.
Please reference following air sniffer log and HCI UART traffic capture. Btmon and Linux syslog related are attached as well.
btmon-pairing-fail.txt syslog-pairing-fail.txt