Hi All, On Thu, Feb 6, 2014 at 12:21 PM, Sandy Chapman <schapman@xxxxxxxxx> wrote: > Hi Anderson, > > On Wed, Feb 5, 2014 at 11:23 AM, Anderson Lizardo > <anderson.lizardo@xxxxxxxxxxxxx> wrote: >> HI Sandy, >> >> On Wed, Feb 5, 2014 at 10:51 AM, Sandy Chapman <schapman@xxxxxxxxx> wrote: >>>>> How do I initiate a Connection Update from the peripheral? >>>> >>>> I never tried this procedure myself, but my guess it that you are >>>> using the incorrect mechanism on the slave role. Take a look at the >>>> "Connection Parameters Update Request" on Vol 3, Part A, Section 4.20. >>>> I believe this is the correct way to request from the slave (from what >>>> I understand while reading the Linux kernel implementation of the >>>> master side). >>>> >>>> Note that when Linux is the master, this command is issued >>>> automatically by the kernel when requested by the slave. >>> >>> I've taken a look at that section and it appears that this is what is >>> used to trigger the Connection Update. It states that the command >>> shall only be issued from the slave to the master. I can confirm that >>> my device is in the slave role using 'hcitool con'. >> >> I think you didn't notice that the section I mentioned is about a >> L2CAP signalling packet, not an HCI command (which in this case is to >> be used on the master side). I suggest you read a bit more on the >> L2CAP section to understand how these signalling packets work. Then >> you can try building such packet with "hcitool cmd" (unless there is >> some support for it on the current kernel, which I didn't check) >> > > Yes, you right, I missed that part. I've built out what my packet > should look like, but I'm having troubles sending it to the > controller. I really am stuck on issuing this packet. It appears that > I need to send an HCI ACL Data Packet which holds a Signalling > Command. This signalling command then holds the connection parameter > update request as it's payload. It looks like 'hcitool cmd' can't send > ACL packets though as the command requires an OGF and OCF which are > part of the HCI Command Packet, not the HCI ACL Data Packet. From what > I can tell, the best chance I'd have is to send it via the l2test tool > over L2CAP, but attempting to use le_public address type doesn't work > (which I believe will send the message over CID 0x0005 - the fixed LE > channel). It fails on getsockopt/setsockopt for the SOL_BLUETOOTH > type. From what I can tell, it requires a kernel with CoC (not sure > what it means or if I have it). I'm really hoping I'm not going to > have to compile the bluetooth kernel module myself to send this > connection update packet. > >>>> You may want to take a look at the "GAP Peripheral Preferred >>>> Connection Parameters" characteristic (see Vol 3, Part C, Section >>>> 12.3). If iPhones reads this characteristic and honours the >>>> parameters, it may help. >>> >>> Unfortunately, it appears Apple explicitly ignores this parameter >>> (section 3.6 in this document >>> https://developer.apple.com/hardwaredrivers/BluetoothDesignGuidelines.pdf). >> >> This is unfortunate. It would be the easiest way to pass custom >> connection parameters IMHO. >> >>> I believe that 'hcitool lecup' is exactly supposed to initiate this >>> process. I've also tried to use 'hcitool cmd' to issue direct commands >>> to the controller (using Vol 3, Part A, Section 4.20 as a guide), but >>> I am having no luck. It's stating that the command is disallowed (not >>> that the parameters are invalid), so I'm guessing there's something >>> else wrong. Since this is directly communicating with the controller, >>> where would the problem be? In the kernel, itself? Could it be a >>> problem with the Broadcom chipset in my MacBook? >> >> "hcitool lecup" is just a helper, it uses the same mechanism that >> "hcitool cmd" uses (and both are just "raw" interfaces to the >> Bluetooth controller). If you are getting an "Invalid Parameters" on >> any of them, is either because you built the packet incorrectly on >> "hcitool cmd" or given invalid values as per the spec. >> >> By the way, I suggest using "btmon" instead of "hcidump", as the >> former has nicer output and is more up-to-date (although I'm not sure >> it supports parsing "LE Connection Update" parameters). >> > > You're right btmon is much nicer and does support recognition of the > LE commands. > >> Best Regards, >> -- >> Anderson Lizardo >> http://www.indt.org/?lang=en >> INdT - Manaus - Brazil > > I know what I'm doing might not be typical, but I really appreciate > your help. If there's any direction you could point me in, I'd be > really thankful. I don't really know what to try next. > > Thanks again, > > Sandy Just wanted to post that I've got this working. However, I've had to write code that will format the signalling packet properly and relay it to the controller via hci (in a similar manner to how hcitool current sends HCI commands). The approach I suggested in my previous email worked (HCI ACL Data Packet containing a Signalling Command of the type Connection Parameter Update Request). This required changes to hci.c (to format and write the new packet to the hci device). See Vol. 2, Part E, 4.1 for Host to Controller HCI flow. See Vol. 2, Part E, 5.4.2 for HCI ACL Data Packet format. See Vol. 3, Part A, 4 for Signalling Packet format. See Vol. 3, Part A, 4.20 for Connection Parameter Update Request format. Since I've got this working, I'm wondering if there is interest from the bluez devs in supporting this going forward? If so, I can likely clean up my code in such a way that it'll allow adding the other signalling packet formats easily. Currently, I've got my specific signalling packet exposed through hcitool (as a new command) as it was convenient to piggyback on it. Since the ACL Data Packets are being sent via HCI, this may be a decent place for this new functionality to stay. Anyway, I'm just wondering if there is any interest as I can likely do some work to add this functionality and I don't think I'm going to be the only one who wishes to be able to request the slave device to renegotiate the connection parameters while a connection is open from the command line. This would be useful in a case where a low energy connection would require a burst of information to be sent (transfer of a large log file, or an image from a sensor for examples). Sandy -- -- 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
