Hi, On Thu, Apr 21, 2011 at 11:24 AM, <Waldemar.Rymarkiewicz@xxxxxxxxx> wrote: > Hi Johan, > >>> --- a/net/bluetooth/hci_event.c >>> +++ b/net/bluetooth/hci_event.c >>> @@ -2369,7 +2369,7 @@ static inline u8 hci_get_auth_req(struct >>> hci_conn *conn) >>> >>> /* If remote requests no-bonding follow that lead */ >>> if (conn->remote_auth == 0x00 || conn->remote_auth == 0x01) >>> - return 0x00; >>> + return conn->auth_type & 0x01; >>> >>> return conn->auth_type; >>> } >> >>Your other patches seem ok to me, but have you verified this >>one with the BITE tester? This logic is directly copied from >>how it is in user space right now and that's something we have >>arrived at after multiple iterations with the BITE tester over >>the last few years. So I'd be very careful when changing it. >> > > No, I did not. I don't have an access to BITE directly, but I will see if I can verify this. > > I simply did some combination of manual tests with three different dongles (2.0 and two 2.1), with sspmode on/off , with auth and encrypt on/off, with required sec_level 1,2,3 in security mode 2 and 4. I remember we discussing something similar regarding LE security, iirc this avoid failing in case there is not possible to generate an authenticated key due to lack of io capability, but I also remember that we do check what type of link key the kernel wants when reading from storage and return not found when e.g authenticated key is required but we have only unauthenticated, so perhaps this is just to make sure we pass some specific BITE test. -- Luiz Augusto von Dentz Computer Engineer -- 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
