Hi Alfonso, On Mon, Sep 29, 2014, Alfonso Acosta wrote: > * With 0x02, (HCI_AUTO_CONN_ALWAYS) there is auto-connection upon > ADV_DIRECT_IND but replacing the device's batteries (power-on > ADV_IND) causes an infinite connection loop: connect->encryption > on->disconnect(due to "encryption on" failing)->connect .... Getting > the report data inside the Device Connected event won't help because > it will never get to that point. Are you sure that you've mapped out the order of events correctly for this case? The way things should be going (based on going through the code - I haven't verified this in practice) on the user space side is: 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, ...); The last step above is what instructs the kernel to initiate encryption. If the mgmt_ev_device_connected would contain hints telling us to call mgmt_unpair + mgmt_pair instead of trying to elevate security your use case should be solvable. If the above order is not what's happening we might be having a race condition between the mgmt and ATT sockets. This race *should* be fixable by ensuring that the mgmt socket has higher priority in the mainloop than the ATT socket. We used to have it like that in the past, but we might have lost it along the way because shared/mgmt.c that uses shared/io.h. As a quick hack to check if these sockets are indeed racing against each other during the same mainloop iteration you could try changing G_PRIORITY_DEFAULT to G_PRIORITY_HIGH in the io_set_read_handler() function in src/shared/io-glib.c (the ATT socket shouldn't be using that but shared/mgmt.c is). Johan -- 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
