Hi Johan, >>>>> ACL Data RX: Handle 70 flags 0x02 dlen 11 [hci0] 28.348460 >>>> SMP: Pairing Response (0x02) len 6 >>>> IO capability: NoInputNoOutput (0x03) >>>> OOB data: Authentication data not present (0x00) >>>> Authentication requirement: Bonding, No MITM, Legacy, No Keypresses (0x01) >>>> Max encryption key size: 16 >>>> Initiator key distribution: EncKey Sign (0x05) >>>> Responder key distribution: EncKey IdKey Sign (0x07) >>>> < ACL Data TX: Handle 70 flags 0x00 dlen 21 [hci0] 28.348510 >>>> SMP: Pairing Confirm (0x03) len 16 >>>> Confim value: 12bd199ba4739a017395109cfa4621b3 >>>>> ACL Data RX: Handle 70 flags 0x02 dlen 21 [hci0] 28.488508 >>>> SMP: Pairing Confirm (0x03) len 16 >>>> Confim value: 41f5f7a6212356d0eefa268f7994844a >>>> < ACL Data TX: Handle 70 flags 0x00 dlen 21 [hci0] 28.488545 >>>> SMP: Pairing Random (0x04) len 16 >>>> Random value: 4e8d532caf34ab845ff243acf6a0a681 >>>>> ACL Data RX: Handle 70 flags 0x02 dlen 6 [hci0] 28.628456 >>>> SMP: Pairing Failed (0x05) len 1 >>>> Reason: Confirm value failed (0x04) >>>> < HCI Command: Disconnect (0x01|0x0006) plen 3 [hci0] 28.628506 >>>> Handle: 70 >>>> Reason: Authentication Failure (0x05) >>>> @ Authentication Failed: 5C:31:3E:5E:54:5E (1) status 0x05 >>> >>> That "Confirm value failed" response still looks like something strange >>> is happening on the remote side - maybe a bug there. Unfortunately I >>> don't really have any other ideas except going for raw bisecting here if >>> you have a kernel version this did work with. >>> >>> The inputs to the function that generates the confirm value are the >>> local and remote public keys and the random number that was sent over >>> the air, so there's not much that can go wrong there - also nothing I >>> can remember that would have changed on the Linux side regarding this >>> for a long time. This of course assumes that the remote device is using >>> this error code correctly and doesn't send it for some other condition. >> >> I bet that the peripheral side wrongly clears some RFU bits. Which >> leads to wrong values for confirm values. > > Johannes, could you try to experiment and see whether this is the issue? > You can temporarily disable Secure Connections support with the command > "btmgmt sc off" I really wonder if we should start using HCI_MON_SYSTEM_NOTE / send_monitor_note to actually send these funky behaviors to the monitor channel once we detect it. At least that way, we would know why we trigger certain PDUs. Or maybe we are doing something specific for SMP with a debugfs switch that allows us to enable to send SMP debug / tigers via monitor channel. An alternative would be to just be able to push the mgmt traffic via monitor channel so we actually have correct timing and can analyze these things together. Regards Marcel -- To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
