Re: LE Connection Update Disallowed

["Jan Rüth" <jan.rueth@rwth-aachen.de>]

On 10/02/14 13:30, Sandy Chapman wrote:
> Hi All,
> 
> On Thu, Feb 6, 2014 at 12:21 PM, Sandy Chapman <schapman-1O7wWW109P4AvxtiuMwx3w@public.gmane.org> wrote:
>> Hi Anderson,
>>
>> On Wed, Feb 5, 2014 at 11:23 AM, Anderson Lizardo
>> <anderson.lizardo-430g2QfJUUCGglJvpFV4uA@public.gmane.org> wrote:
>>> HI Sandy,
>>>
>>> On Wed, Feb 5, 2014 at 10:51 AM, Sandy Chapman <schapman-1O7wWW109P4AvxtiuMwx3w@public.gmane.org> 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
> 

Hi Sandy,

would you mind sharing your code? I tried to implement it and I can see
the connection update in btmon but afterwards I cannot send data from
the slave to the master via my l2cap socket.


Thanks
 Jan