Answers checklist
AT+GMR
AT+GMR
AT version:3.5.0.0-dev(8bfb16f - ESP32C6 - Jan 6 2025 09:10:51)
SDK version:v5.1.5-196-g64849cb703-dirty
compile time(5302cdc):Jan 21 2025 09:44:51
Bin version:v1.0.1.0(ESP32C6-4MB)
OK
ESP-AT Firmware Source
Firmware built from master with a lib update provided by Rainbow.Cai in Espressif's support team to support pairing requirements on characteristics.
Hardware Information
ESP32-C6 DevKitC
Power Supply used
USB
What is the expected behavior?
If the client (windows for example) removes its record of the pairing, but the server (ESP) does not, the client should be able to successfully pair to the server again.
I have tested this with with an iPhone (Server) running LightBlue and Windows (Client), and windows correctly initiates the pairing to the iPhone again.
What is the actual behavior?
Once the pairing is removed on the client side, then the client attempts to pair again, no BLESEC messages are seen by the ESP32 and the authentication times out in Windows.
The ESP32 does remove its pairing, so it knows the original one is not valid.
Probability of recurrence
100%
AT+SYSRAM?
AT+SYSRAM?
+SYSRAM:236348,224324
OK
Steps to reproduce
- Configure an ESP32-C6 to be a BLE Server with pairing requirements.
- Use a Windows client to connect and initiate the pairing.
- Once complete disconnect
- Remove the pairing on the Windows client but not the ESP32 server
- Use the Windows client again to connect and initiate a pairing
- The authentication times out without presenting any messages over the command port output
AT command port output
AT+CWINIT=0
OK
AT+BLEINIT=2
OK
AT+BLEADDR?
+BLEADDR:"40:4c:ca:51:48:f6"
OK
AT+BLESECPARAM=13,1,16,3,3
OK
AT+BLENAME="TPG_0000069666"
OK
AT+BLEADVPARAM=50,50,0,0,7,0
OK
AT+BLEADVDATA="02010603031DBA0F095450475F30303030303639363636"
OK
AT+BLEADVSTART
OK
+BLECONN:0,"d4:54:8b:fd:6d:0c"
+BLECFGMTU:0,203
+BLECONNPARAM:0,12,12,12,0,960
+BLESECNCREQ:0,729505
+BLECONNPARAM:0,48,48,48,0,960
AT+BLECONFREPLY=0,1
OK
+BLEAUTHCMPL:0,0
+BLECONNPARAM:0,12,12,12,0,960
+WRITE:0,1,2,1,2,02
+BLECONNPARAM:0,48,48,48,0,960
+WRITE:0,1,2,1,2,00
+BLEDISCONN:0,"d4:54:8b:fd:6d:0c"
AT+BLEADVSTART
OK
+BLECONN:0,"d4:54:8b:fd:6d:0c"
+BLECFGMTU:0,203
+BLECONNPARAM:0,12,12,12,0,960
+BLECONNPARAM:0,48,48,48,0,960
+BLEDISCONN:0,"d4:54:8b:fd:6d:0c"
AT log port output
connection established; status=0 handle=0 our_ota_addr_type=0 our_ota_addr=4083adcf:00:15:4082c000:00:42176c78
our_id_addr_type=0 our_id_addr=4083adc1:00:15:4082c000:00:42176c78
peer_ota_addr_type=0 peer_ota_addr=4083add6:00:15:4082c000:00:42176c78
peer_id_addr_type=0 peer_id_addr=4083adc8:00:15:4082c000:00:42176c78
conn_itvl=48 conn_latency=0 supervision_timeout=960 encrypted=0 authenticated=0 bonded=0
advertise complete; reason=0mtu update event; conn_handle=0 cid=4 mtu=203
subscribe event; conn_handle=0 attr_handle=8 reason=1 prevn=0 curn=0 previ=0 curi=1
handle = 8 , ret_node->handle=65535
handle = 8 , ret_node->handle=16
handle = 8 , ret_node->handle=65535
handle = 8 , ret_node->handle=65535
handle = 8 , ret_node->handle=20
handle = 8 , ret_node->handle=65535
handle = 8 , ret_node->handle=65535
get node by handle fail
connection updated; status=0 handle=0 our_ota_addr_type=0 our_ota_addr=4083ad7f:00:15:4082c000:00:42176c78
our_id_addr_type=0 our_id_addr=4083ad71:00:15:4082c000:00:42176c78
peer_ota_addr_type=0 peer_ota_addr=4083ad86:00:15:4082c000:00:42176c78
peer_id_addr_type=0 peer_id_addr=4083ad78:00:15:4082c000:00:42176c78
conn_itvl=12 conn_latency=0 supervision_timeout=960 encrypted=0 authenticated=0 bonded=0
connection updated; status=0 handle=0 our_ota_addr_type=0 our_ota_addr=4083ad7f:00:15:4082c000:00:42176c78
our_id_addr_type=0 our_id_addr=4083ad71:00:15:4082c000:00:42176c78
peer_ota_addr_type=0 peer_ota_addr=4083ad86:00:15:4082c000:00:42176c78
peer_id_addr_type=0 peer_id_addr=4083ad78:00:15:4082c000:00:42176c78
conn_itvl=48 conn_latency=0 supervision_timeout=960 encrypted=0 authenticated=0 bonded=0
subscribe event; conn_handle=0 attr_handle=8 reason=2 prevn=0 curn=0 previ=1 curi=0
handle = 8 , ret_node->handle=65535
handle = 8 , ret_node->handle=16
handle = 8 , ret_node->handle=65535
handle = 8 , ret_node->handle=65535
handle = 8 , ret_node->handle=20
handle = 8 , ret_node->handle=65535
handle = 8 , ret_node->handle=65535
get node by handle fail
disconnect; reason=531 handle=0 our_ota_addr_type=0 our_ota_addr=4083ae2b:00:15:4082c000:00:42176c78
our_id_addr_type=0 our_id_addr=4083ae1d:00:15:4082c000:00:42176c78
peer_ota_addr_type=0 peer_ota_addr=4083ae32:00:15:4082c000:00:42176c78
peer_id_addr_type=0 peer_id_addr=4083ae24:00:15:4082c000:00:42176c78
conn_itvl=48 conn_latency=0 supervision_timeout=960 encrypted=0 authenticated=0 bonded=0
More Information.
No response
Answers checklist
AT+GMR
AT+GMR
AT version:3.5.0.0-dev(8bfb16f - ESP32C6 - Jan 6 2025 09:10:51)
SDK version:v5.1.5-196-g64849cb703-dirty
compile time(5302cdc):Jan 21 2025 09:44:51
Bin version:v1.0.1.0(ESP32C6-4MB)
OK
ESP-AT Firmware Source
Firmware built from master with a lib update provided by Rainbow.Cai in Espressif's support team to support pairing requirements on characteristics.
Hardware Information
ESP32-C6 DevKitC
Power Supply used
USB
What is the expected behavior?
If the client (windows for example) removes its record of the pairing, but the server (ESP) does not, the client should be able to successfully pair to the server again.
I have tested this with with an iPhone (Server) running LightBlue and Windows (Client), and windows correctly initiates the pairing to the iPhone again.
What is the actual behavior?
Once the pairing is removed on the client side, then the client attempts to pair again, no BLESEC messages are seen by the ESP32 and the authentication times out in Windows.
The ESP32 does remove its pairing, so it knows the original one is not valid.
Probability of recurrence
100%
AT+SYSRAM?
AT+SYSRAM?
+SYSRAM:236348,224324
OK
Steps to reproduce
AT command port output
AT log port output
More Information.
No response