BT Classic GAP bond list corrupt or invalid after removing bond (IDFGH-3432)

[JHedgesBartec]

Environment

• Module or chip used: ESP32-WROOM-32
• IDF version: v4.0.1 Release
• Build System: CMake
• Compiler version SysGcc 8.2.0
• Operating System: Windows
• (Windows only) environment type: IDE below for build process
• IDE: VisualStudio and VisualGDB
• Power Supply: external 3.3V

Problem Description

After a device bond has been removed the bond list is ether corrupt or invalid. This is most evident within 1 second of a disconnect.

Expected Behavior

Bond to be removed and API to access bond list

Actual Behavior

Either the bond list is not updated despite esp_bt_gap_remove_bond_device() returning error free or the bond count returned by esp_bt_gap_get_bond_device_num() is updated and the last pairing provided by esp_bt_gap_get_bond_device_list() is zero'd

Steps to reproduce

1. Pair multiple devices using BT Classic legacy PIN SPP communication
2. Connect to a device then disconnect (data doesn't have to be transferred and this step isn't always necessary)
3. Remove one of the bonds with esp_bt_gap_remove_bond_device()
4. Read back the bond list using esp_bt_gap_get_bond_device_num() and esp_bt_gap_get_bond_device_list()

Debug Logs

The ESP has been wiritten with an emulation of the iWRAP 3 interface.

• Debug log from the bond not being removed:
  I (40261) SPP_CB: event 27
  I (40261) SPP_CB: ESP_SPP_CLOSE_EVT
  SET CONTROL AUTOCALL
  I (40371) Autocall: Stopping Autocall
  I (40372) CL_GAP_CB: event 1
  AT
  OK
  SET BT PAIR 00:07:80:FF:D9:CF
  I (40518) BT Pairing: Pair Removed OK : 00 07 80 ff d9 cf
  I (40518) BT Pairing: 2 devices paired
  AT
  OK
  SET CONTROL AUTOCALL 7101 1500 RFCOMM
  I (40593) Autocall: Module has 2 pairings
  I (40593) Autocall: Module has 2 pairings
  I (40593) Paired device mac: 00 07 80 ff d9 cf
  I (40596) Paired device mac: 9c b6 d0 c6 bc aa
  I (40601) Autocall: Try link to a previous connection
  I (40607) Autocall: Start looking for previous paired BDA to connect to
  I (40615) Autocall: calling : 00 07 80 ff d9 cf
  I (40624) CL_GAP_CB: event 1
  AT
  OK
  W (41011) BT_APPL: bta_jv_rfc_port_to_cb(port_handle:0x3):jv handle:0x0 not FOUND
  W (41011) BT_RFCOMM: port_rfc_closed RFCOMM connection in state 3 closed: Closed (res: 19)
  I (41079) SPP_CB: event 8
  I (42115) Autocall: calling : 9c b6 d0 c6 bc aa
  I (42136) CL_GAP_CB: event 1
  I (42833) SPP_CB: event 8
  I (43615) Autocall: calling : 00 07 80 ff d9 cf
  I (43618) CL_GAP_CB: event 1

• Debug log from the Zero'd case:
  I (144098) SPP_CB: event 27
  I (144098) SPP_CB: ESP_SPP_CLOSE_EVT
  W (144994) BT_APPL: bta_jv_rfc_port_to_cb(port_handle:0x3):jv handle:0x0 not FOUND
  W (144994) BT_RFCOMM: port_rfc_closed RFCOMM connection in state 3 closed: Closed (res: 19)
  SET CONTROL AUTOCALL
  I (145679) Autocall: Stopping Autocall
  I (145680) CL_GAP_CB: event 1
  AT
  OK
  SET BT PAIR 00:07:80:FF:D9:CF
  I (147327) BT Pairing: Pair Removed OK : 00 07 80 ff d9 cf
  I (147327) BT Pairing: 2 devices paired
  E (147330) BT_APPL: bta_gattc_mark_bg_conn unable to find the bg connection mask for: 00:07:80:ff:d9:cf
  AT
  OK
  SET CONTROL AUTOCALL 7101 1500 RFCOMM
  I (147400) Autocall: Module has 1 pairings
  I (147401) Autocall: Module has 1 pairings
  I (147401) Paired device mac: 00 00 00 00 00 00
  I (147404) Autocall: Try link to a previous connection
  I (147410) Autocall: Start looking for previous paired BDA to connect to
  I (147418) Autocall: calling : 00 00 00 00 00 00
  I (147429) CL_GAP_CB: event 1

[Alvin1Zhang]

@JHedgesBartec Thanks for reporting, we will look into.

[JHedgesBartec]

I have confirmed the failure to remove bond behaviour through two different ways. Attached are two C files which are based upon the SPP Acceptor demo.
Included in Source.zip are two different files, case_1.c is where all bonds are removed on boot of the module, case_2.c is where a bond is removed as soon as the SPP connection is closed.

Note both cases are when more than one bond is present at the time of removing them.

Source.zip

[ghost]

Hi @JHedgesBartec

We have optimized SPP disconnection procedure inside via an MR.
Please wait for sometime and pull the lastest master, if this issue still exist, we will look into it as soon as possible.

Thanks
Weitianhua