Hi Ville, Vinicius, On Tue, Dec 07, 2010 at 12:47 AM -0800, Ville Tervo wrote: > Hi Brian, > > On Mon, Dec 06, 2010 at 04:35:51PM -0800, ext Brian Gix wrote: > > 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. I would like to try Vinicius' patch that (may) address this, but again I do not have access to infradead, although I think gitorious, which you used before, was not a problem. > > > > 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. > > > > And in usb case CMD and ACL are even using different endpoints. > > > 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. > > True. > > > 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. > > > > How about implement waiting on l2cap_sock_shutdown() like for ERTM. > User space > could then call shutdown() before closing the socket so make sure the > data is > sent or timeout occurred. If I understand l2cap_sock_shutdown() correctly, then I think this is the correct solution. The socket mode would be BASIC, and the channel (dcid) would be fixed-4 (or perhaps fixed-5 or fixed-6 as well), but instead of waiting for an ack, it would be waiting on the EVT_NUM_COMP_PKTS, that indicates the number of outstanding ACL packets on the connection is Zero, with the rest of the logic unchanged. > > Would this be enough to solve the problem? > > > 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. > > I have seen this problem but didn't dig it deeper. > > -- > Ville -- 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
