Hi Marcel, > you can not send HTML emails here. The mailing list will just reject you. Sorry about that, I didn't even know that my email client was inserting HTML tags. >> We are dealing with an HID device which sends meaningful information in ADV_IND reports and to which we want to connect when receiving ADV_DIRECT_IND reports. >> >> Without kernel support for auto-connecting on ADV_IND while still forwarding ADV_DIRECT_IND to userland, we are forced to keep active scanning on so that the content of ADV_IND reports isn't lost. >> I meant "for auto-connecting on ADV_DIRECT_IND while still forwarding ADV_IND to userland", sorry > I still think that what you really want is actually using Action 0x02 since you know the remote device address and you want to connect it. It does not matter if it happens via ADV_DIRECT_IND or ADV_IND in the end. However in case it happens via ADV_IND you want to get the advertising data and for that I am proposing to get it via Device Connected event. Unfortunately, that is not good enough for this device. Let me give you some context. This device doesn't have non-volatile memory, so, when its batteries are replaced it loses the bonding information (i.e. LTK). * When bonded, the device sends ADV_DIRECT_IND. * When not bonded (fresh from factory or due to the batteries being replaced) it sends ADV_IND containing a special message (let's call it "power-on") reflecting that it's not bonded. When this happens we need to regenerate the device's LTK and rebond. Action 0x02 (even when forwarding the the ADV_IND report content via Device Connected event) is not good enough. In fact, none of the current auto-connect actions work for this device: * With 0x00, (HCI_AUTO_CONN_REPORT) the content of ADV_IND is forwarded to userland but there is no auto-connection upon ADV_DIRECT_IND * With 0x01, (HCI_AUTO_CONN_DIRECT) there is auto-connection upon ADV_DIRECT_IND but if the device's batteries are removed (power-on ADV_IND) the device is not reconnected. * 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. The alternatives are 1. Keep using passive scanning and add/modify an action to connect upon ADV_DIRECT_IND and forward ADV_IND to userland (to have the opportunity or rebonding). 2. Constantly do active scanning, which, again, we would like to avoid. Thanks, -- 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
