On Fri, Apr 20, 2012 at 7:45 PM, Mike <puffy.taco@xxxxxxxxx> wrote: > Hi Tom, > > On Fri, Apr 20, 2012 at 7:28 PM, Tom Allebrandi <wyrles@xxxxxxxxx> wrote: >> Hi Mike - >> >>> -----Original Message----- >>> From: linux-bluetooth-owner@xxxxxxxxxxxxxxx [mailto:linux-bluetooth- >>> owner@xxxxxxxxxxxxxxx] On Behalf Of Mike >>> Sent: Friday, April 20, 2012 3:40 PM >>> To: linux-bluetooth >>> Subject: PTS / linkkey issue >>> >>> Hi, >>> >>> I'm having a somewhat relate issue to Vishal AGARWAL [1]. The trouble I >>> have is that the PTS system is requesting auth type 0, and Bluez happily >>> obliges. This leaves the PTS device as temporary, and BlueZ then deletes >> this >>> device after the end of the connection. This prevents me from being able >> to >>> pass TP/OOR/BV-02-I: [HF reconnects to AG]. The code is designed to >>> periodically reconnect to the AG after it detects a link timeout. But, if >> BlueZ >>> has deleted the device, I don't do that. This also somewhat applies to >> the >>> A2DP test cases, as my device must be left in pairing mode in order for >> the >>> tests to pass. >>> >>> So, my question to people who have used PTS, is there a way to get the PTS >>> to perform a pairing that is not 0x00 MITM Protection Not Required - No >>> Bonding. Numeric comparison with automatic accept allowed? I'm using an >>> older kernel that doesn't have the mgmt interface (2.6.33 with some >>> features/fixes backported from newer kernels) but am using the latest >> BlueZ >>> from git (at least of a month ago or so). But even so, the proposal of >> keeping >>> the linkkey around for the ACL session would be useless, I think, because >> the >>> intent is to have a link timeout event. >>> >>> Thanks, >>> Mike >>> >>> [1] http://www.spinics.net/lists/linux-bluetooth/msg23346.html >>> -- >>> 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 >> >> PTS may be requesting "no man in the middle protection" but what is your >> system (BlueZ) requesting? If your system is also requesting no MITM then >> that would explain what you are seeing. >> >> If your system is requesting "man in the middle protection", then I think >> that is what gets used resulting in an authenticated link key. Do you have >> an HCIdump or PTSPV trace around so we can see what your device is asking >> for. >> >> At least that's the way I read the core spec. I could be wrong, that area is >> a little confusing :-). >> >> --- tom >> tom allebrandi >> wyrles@xxxxxxxxx >> > > There's not much to the trace. The PTS' response to the HCI IO > Capability request event gives a 0x00. The default in the BlueZ code > is 0x04, but it appears it gives that up and takes the 0x00. In > pairing with an iPhone, I see BlueZ respond with a 0x04 code, and > eventually both sides have indicated 0x04. > > The bluetoothd log with PTS containted: > > bluetoothd[501]: plugins/hciops.c:link_key_notify() key type 0x04 old > key type 0x04 > bluetoothd[501]: plugins/hciops.c:link_key_notify() local auth 0x00 > and remote auth 0x00 > > Thanks, > Mike I see that there are at least two open issues filed against PTS on this: https://www.bluetooth.org/pts/issues/view_issue.cfm?id=6925 https://www.bluetooth.org/pts/issues/view_issue.cfm?id=6942 These have been open for almost 2 years! Tom, is this something that is actively being worked on by the Bluetooth SIG? I see it was assigned to you at one point. Does BlueZ have something wrong? It seems like an option to select General Bonding would fix things for a bunch of people! Thanks, Mike -- 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
