Hi, On Thu, Feb 6, 2014 at 6:48 PM, Caleb Reinhold <creinhold@xxxxxxxxxxxxxxxxxxx> wrote: > It seemed that calling g_attrib_register() in the connection callback might > be causing the client to start listening for indications and notifications > too late, but registering right after the gatt_connect() call doesn't seem > to help. Nor does placing a watch on the GIOChannel inside bt_io_connect(), > so registering earlier doesn't appear to be the right approach. Do you know > why we keep missing this initial indication on medium security, and how we > might fix this issue? If I remember correctly, the issue is in the kernel: if connect() is called when security level is medium, the socket only gets POLLOUT once SMP pairing finishes, and any ATT PDU received during that time is lost. Note that it's almost certain that your device is sending the indication without requiring encryption. Otherwise, it would have sent a Security Request (which triggers a Pairing Request from the Linux side) and wait for the encryption to be enabled before sending the indication. If that was the case, the kernel would deliver the ATT PDU to gatttool after encryption is enabled and it would work as expected. PS: Please, as common netiquette, avoid top-posting (i.e. answer before the original message) and quote only the text that gives context to your answer. Best Regards, -- Anderson Lizardo http://www.indt.org/?lang=en 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
