Hi Brian, On 17:22 Mon 07 Feb, Brian Gix wrote: > On 2/7/2011 4:26 PM, Brian Gix wrote: > > > >Testing of Shorter than 16 octet keys. > > > >In smp_cmd_pairing_random() when the STK is generated, it needs to be > >truncated to the MIN of conn->preq[4] and conn->pres[4]. > > > >This Min value may need to be saved for later as well, because it needs > >to also limit the LTK key exchange. > > > >This failure showed up with the PTS tool, and at least one other device > >during the days testing. I have mocked up a fix, but have not had a > >chance to test it yet. > > > > First, thanks for the reports. This particular issue should be fixed soon. > > PTS also did not like that we request No Bonding, but request to > exchange keys. I am not sure who is at fault there. At first > glance, exchanging keys insinuates a bonded relationship, so I don't > know what it means to request key exchange but not bond. I think > both sides need to agree to bond (bit 0x01 in offset 3 (4th octet) > of the req and res) to remember the exchanged keys, but exchanging > keys should still be OK for the duration of that session at least. > They would then be discarded when the connection ended. > > It also may not make sense to request Bonding, but not have keys to > exchange, because I am not sure if you are really bonded if you have > no keys exchanged with the remote device. You could always just > remember the remote device's BD Addr, I suppose and choose to accept > or reject no-security connections based on that. > > I am sorry, the above is mostly just me thinking out loud. I don't > know for sure if any of that is actually correct. > So, I will add something to the thinking out loud session ;-) seems to me that the tests were written assuming that most of the limitations are in the slave, when some of them find a limited (for now) SM implementation in the master side some things are not so clear. > > -- > Brian Gix > bgix@xxxxxxxxxxxxxx > Employee of Qualcomm Innovation Center, Inc. > Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum Cheers, -- Vinicius -- 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
