Hi Johan and Marcel, As you guys suggested, including ADV_IND in the Device Connected event made the trick (for which I just submitted a patch). Everything goes well if I disconnect when rebonding (using Unpair Device with Disconnect=0x01). However, I am struggling to go one step further and rebond without disconnecting (using Unpair Device with Disconnect=0x00) before the security elevation happens. The sequence of "events" is exactly as Johan described: > 1. mgmt_ev_device_connected (connected_callback() in adapter.c) > 2. Connection indication on ATT server socket (src/attrib-server.c) > 3. device_attach_attrib() called (due to step 2) > 4. bt_io_set(io, ..., BT_IO_SEC_MEDIUM, ...); Now I can detect the need to rebond in (1), which gives me control over the next steps. However, since rebonding is asynchronous, I don't know a simple way to ensure it is done before the security elevation happens. My ideas so far: * Stall (3) through synchronization primitives until the rebonding is done, which sounds horrible. * Cancel (3) and somehow force an ATT reconnection (2) once the rebonding is done, which in turn would cause another security elevation, but I don't know how (I am probably making wrong assumptions about how the ATT socket works). Do you have any suggestions? Thanks, Fons On Mon, Sep 29, 2014 at 4:49 PM, Alfonso Acosta <fons@xxxxxxxxxxx> wrote: >> >> if it can not store its LTK, then why doesn't it use a key hierarchy (as defined in the Bluetooth specification) so that it can restore its keys after reboot. If it remembers its Bluetooth address, then it could clearly remember a single master key. >> >> But seriously, if you can remember your BD_ADDR, then you might want to remember your LTK as well. Just a hint here. > > > Thanks for the hint, I wasn't familiar with "key hierarchies". > >> So the encryption trigger is not done by the kernel. It is actually done by userspace when you have an existing LTK. The kernel will auto-conect the device with low security and then userspace will move it to medium security in case we have an LTK. It will also move it to medium security for all HID devices since that is mandatory. >> > [...] >> Having the advertising data in Device Connected event will actually allow you to do exactly what you want. It would allow you to utilize Unpair Device (with Disconnect 0x00) and Pair Device to recreate the bonding. All without ever disconnecting the link. >> >> The important piece of detail is that the security elevation from low to medium does not happen when the device is detected as initial powered on. So instead of security elevation, you do a re-bonding which will give you the encrypted link HID requires and also the new LTK. > > Oh, I see. I was wrongly assuming that the encryption elevation was > also done in the kernel without userspace involvement. Then, adding > the contents of the ADV_IND report to the "Device Connected event" > should indeed be good enough. I will try it out and send a patch if it > works. > > >> So before trying to redefine the Add Device command semantics, I would clearly go for adding the advertising data to Device Connected event and see if that gets you where you need to go. > > Will do, thanks! > > > > -- > Alfonso Acosta > > Embedded Systems Engineer at Spotify > Birger Jarlsgatan 61, Stockholm, Sweden > http://www.spotify.com -- Alfonso Acosta Embedded Systems Engineer at Spotify Birger Jarlsgatan 61, Stockholm, Sweden http://www.spotify.com -- 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
