Hi, This series fixes issues when doing reverse GATT service discovery over LE. There is still one open issue: If BlueZ creates a device without bonding (i.e. CreateDevice() D-Bus method), but the remote requests SMP pairing with "Security Request", at the end of the pairing a reverse GATT service discovery is issued, *regardless* of BlueZ being the initiator or not. BlueZ should only do reverse discovery if it is the acceptor (see comments on the device_bonding_complete() function on src/device.c). To fix this, I think we need to have a more robust way to check whether we are initiator or acceptor, instead of simply checking for an active bonding request. Currently, if BlueZ receives keys from kernel over mgmt, device_bonding_complete() is eventually called, and if there is no active bonding, BlueZ assumes to be an acceptor. In any case, with these patches we make sure this spurious service discovery will not crash BlueZ or create leaks. It is also applicable for "normal" reverse service discovery as well. Best Regards, -- Anderson Lizardo Instituto Nokia de Tecnologia (INdT) Manaus - Brazil -- 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
