Additional point-- > -----Original Message----- > From: linux-bluetooth-owner@xxxxxxxxxxxxxxx [mailto:linux-bluetooth- > owner@xxxxxxxxxxxxxxx] On Behalf Of Brian Gix > Sent: 06 December, 2010 4:36 PM > To: linux-bluetooth@xxxxxxxxxxxxxxx > Subject: EVT_NUM_COMP_PKTS and LE, GATT and SM > > Hi All, > > I've have encountered a problem while using the gatttool, where my > write > commands get clobbered by the LE ACL being disconnected prior to the > ATT > (fixed channel 4) WRITE_CMD being sent over the LE based ACL link. > > I believe this is fundamentally due to there being no dependency on the > EVT_NUM_COMP_PKTS event when gatttool decides that the WRITE_CMD has > been > successfully sent. There is multiple parts to this. > > 1. In User space, the WRITE_CMD pkt is written to the socket. Gatttool > erroneously considers a successful socket write as completion, > disconnects > the socket and exits. > > 2. In Kernel space, the ACL packet is added to an ACL queue, which is > separate from the CMD queue, which can allow either the Disconnect > request, > or the ACL packet to be sent over the H4 link to the baseband. > > 3. In the baseband, due to LE clocking (and possible other baseband > activity) the ACL packet could be received first, and the Disconnect > CMD > second, and still result in the connection being detached prior to Tx > of the > ACL packet containing the ATT WRITE_CMD. > > This is not an issue with any of the ATT READ/FIND/MTU or WRITE_REQ > transactions, because they require a response from the server. I > believe > for ATT, this problem is restricted to the WRITE_CMD only, due to it's > unacknowledged nature. > > However, this will also be an issue with the LE Security Manager, > because as > stated in the Core Spec v4.0, Vol 3, in the last paragraph of 3.6.1 Key > Distribution on page 630 (of 656): > > > Key distribution is complete in the device sending the final > key > when it receives > > the baseband acknowledgement for that key and is complete in > the > receiving > > device when it receives the final key being distributed. > > This is intended to prevent exactly the kind of problem I am > experiencing > with the ATT WRITE_CMD, and the acknowledgement from the baseband can > only > be the EVT_NUM_COMP_PKTS event. > > While talking to my colleagues here, we were thinking that the cleanest > method to get this accomplished would be by using the "select" method > with the ATT socket, where the socket could be marked as non-writable > by the kernel driver until the EVT_NUM_COMP_PKTS is received. The User > space code could then wait for the socket to become writeable before > issuing the socket disconnect. This solution could be isolated to LE links (and perhaps even fixed channel 4) because of the strict cmd-resp nature of ATT transactions. This would cause the inability to queue multiple WRITE_CMDS before disconnecting however. > If the Security manager is totally within the kernel, it probably does > not > have to do as much work, however it does still need to wait on the > EVT_NUM_COMP_PKTS before disconnecting the remote device. > > Has anybody else observed this issue with ATT WRITE_CMD? It could be > getting > exacerbated by slow (115Kbps) H4 links that I am using, however the > hcidump > tool confirms that the disconnect happens prior to the > EVT_NUM_COMP_PKTS. > > > > Brian Gix > bgix@xxxxxxxxxxxxxx > Employee of Qualcomm Innovation Center, Inc. > Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum > > > > -- > 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 -- 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
