Open nashif opened 7 years ago
by Johan Hedberg:
I suspect this might be because the flow control events happen "before their time" on an emulated setup (i.e. a btvirt bug), however something like the following should fix the endless repetition of failed messages:
--- a/subsys/bluetooth/host/smp.c
+++ b/subsys/bluetooth/host/smp.c
@@ -3432,7 +3432,10 @@ static void bt_smp_recv(struct bt_l2cap_chan *chan, struct net_buf *buf)
if (!atomic_test_and_clear_bit(&smp->allowed_cmds, hdr->code)) {
BT_WARN("Unexpected SMP code 0x%02x", hdr->code);
- smp_error(smp, BT_SMP_ERR_UNSPECIFIED);
+ /* Don't send error responses to error PDUs */
+ if (hdr->code != BT_SMP_CMD_PAIRING_FAIL) {
+ smp_error(smp, BT_SMP_ERR_UNSPECIFIED);
+ }
return;
}
Reported by Vinayak Kariappa Chettimada:
Issue: Trying to get an encrypted security level 2 connection between two tests/bluetooth/shell application running in QEMU resulted in a livelock of SMP pairing failed PDUs exchanged between the two BLE connections.
Test setup:
CONFIG_BT_L2CAP_RX_MTU=247
CONFIG_BT_L2CAP_TX_MTU=247
CONFIG_BT_ATT_TX_MAX=6 {code}
btmon log: {code} < ACL Data TX: Handle 0 flags 0x00 dlen 11 #107382 [hci2] 66690.567967 SMP: Pairing Request (0x01) len 6 IO capability: NoInputNoOutput (0x03) OOB data: Authentication data not present (0x00) Authentication requirement: Bonding, No MITM, SC, No Keypresses (0x09) Max encryption key size: 16 Initiator key distribution: EncKey IdKey Sign (0x07) Responder key distribution: EncKey IdKey Sign (0x07)
(Imported from Jira ZEP-2620)