mgagic
commented
2 years ago Additional logs with NimBLE logs set to debug:
successful case (which was second or third successful attempt after paiting)
I (198331) BLE_SRV NIMBLE: CON HANDLER 0
ble_hs_hci_cmd_send: ogf=0x08 ocf=0x0016 len=2
0x16 0x20 0x02 0x00 0x00
Command Status: status=0 cmd_pkts=5 ocf=0x16 ogf=0x8
LE LTK Req. handle=0 rand=e8ef07f9c4c89a08 encdiv=16455
looking up our sec; peer_addr_type=0 peer_addr=0x3f 0x0e 0x5b 0xe3 0xdb 0xf4 ediv=0x4047 rand=0xe8ef07f9c4c89a08
ble_hs_hci_cmd_send: ogf=0x08 ocf=0x001a len=18
0x1a 0x20 0x12 0x00 0x00 0x45 0x8c 0xec 0xed 0xaf 0x4d 0x4a 0x4a 0xa0 0x45 0x17 0xbf 0xa0 0x81 0x4b 0xb8
Command complete: cmd_pkts=5 ogf=0x8 ocf=0x1a status=0 handle=0
Encrypt change: status=0 handle=0 state=1
D (198551) BLE_SRV NIMBLE: bleprph_gap_event:584 ENC_CHANGE_EVENT
D (198551) BLE_SRV NIMBLE: bleprph_gap_event:593 subscribe event; conn_handle=0 attr_handle=8 reason=3 prev_notify=0 cur_notify=0 prev_indicate=0 cur_indicate=1unsuccessful case after that, in the same life-cycle:
I (238551) BLE_SRV NIMBLE: CON HANDLER 0
ble_hs_hci_cmd_send: ogf=0x08 ocf=0x0016 len=2
0x16 0x20 0x02 0x00 0x00
LE LTK Req. handle=0 rand=e8ef07f9c4c89a08 encdiv=16455
looking up our sec; peer_addr_type=0 peer_addr=0x3f 0x0e 0x5b 0xe3 0xdb 0xf4 ediv=0x4047 rand=0xe8ef07f9c4c89a08
ble_hs_hci_cmd_send: ogf=0x08 ocf=0x001a len=18
0x1a 0x20 0x12 0x00 0x00 0x45 0x8c 0xec 0xed 0xaf 0x4d 0x4a 0x4a 0xa0 0x45 0x17 0xbf 0xa0 0x81 0x4b 0xb8
Command complete: cmd_pkts=4 ogf=0x8 ocf=0x1a status=0 handle=0
D (240591) BLE_SRV NIMBLE: bleprph_gap_event:584 ENC_CHANGE_EVENT
D (240601) BLE_SRV NIMBLE: bleprph_gap_event:540 disconnect; reason=19 It seems like after commands
ble_hs_hci_cmd_send: ogf=0x08 ocf=0x0016 len=2 - LE Read Remote Features command
ble_hs_hci_cmd_send: ogf=0x08 ocf=0x001a len=18 - LE Long Term Key Request Reply command
ENC_CHANGE_EVENT happens in both cases, but after that instead of a subscribe event, there is a disconnect
rahult-github
Hi,
I am working on a project that uses an esp32-wroom-32d as a communication module in a bigger system. It is using esp-idf v3.3.4 (it cannot be updated at the moment). I have already checked related issues (notably #8) and the fixes are already included in the version that we have. Still, there are some issues and they happen with iOS only. We have a dedicated app (developed with flutter) that's used with the device, but the crash occurs with nRF Connect as well.
When first connection is established, it is successful; one of the subsequent connections cause the crash. Sometimes, the crash won't be caused by the first subsequent connection. But if phone's BT is turned off and on, and the device hasn't been removed from the saved deviced in between, the next connection will crash the device.
The crash seems to happen after a failed assert:
assertion "ble_hs_hci_ack == ((void *)0)" failed: file "esp-idf/components/nimble/nimble/nimble/host/src/ble_hs_hci.c", line 370, function: ble_hs_hci_rx_ackbut it's not always in the same functionassertion "ble_hs_hci_ack == ((void *)0)" failed: file "esp-idf/components/nimble/nimble/nimble/host/src/ble_hs_hci.c", line 313, function: ble_hs_hci_cmd_txlogs: 1st try - success:
2nd try (same lifecycle) - crash:
backtrace:
In this specific test case, I see that device constantly shows number of stored bondings: 0, this isn't always the case so I'm not sure what happens here. But usually, it will have the phone's data stored and it will show the number of previous bonds.
our setup:
bleprph_on_sync
menuconfig settings for Nimble
I can provide the logs with NimBLE logging set to DEBUG, but since this already seems like a lot of information, I'm not attaching them right away.
Can anyone help with some pointers - what could be the issue? what should I check/setup differently? Let me know if I should provide any additional information.