LE Connection Update Disallowed

LE Connection Update Disallowed

[Sandy Chapman]

Hi All,

I've got a problem with issuing an LE Connection Update via the
hcitool's lecup command and I'm not sure why. Based on what I've read
online, this should be working.

Central: iPhone 5
Peripheral: Linux Mint 15 running kernel 3.11.0-12-generic (running in
a VM on a Mac Book)
I'm using a built from source Bluez off tag 5.14.

I establish an LE connection between the devices. The central
successfully discovers the services and characteristics and can read
them. Once the connection is established, I run this command on the
Linux peripheral:

$ sudo ./bin/hcitool lecup --handle 64 --min 24 --max 50 --latency 4
--timeout 550
>>> Could not change connection params: Input/output error(5)

In my hcidump -X, I get this:

< HCI Command: LE Connection Update (0x08|0x0013) plen 14
  0000: 40 00 18 00 32 00 04 00  26 02 01 00 01 00        @...2...&.....
> HCI Event: Command Status (0x0f) plen 4
    LE Connection Update (0x08|0x0013) status 0x0c ncmd 1
    Error: Command Disallowed

In my limited understanding, it looks like the command isn't being
issued. It doesn't appear that it's the iPhone rejecting the command,
but something local to the Linux install. Running hciconfig lestates
shows that all states are permitted ("YES" beside every entry).

The Bluetooth Spec (Volume 2, Part E, section 7.8.18) states that this
command shall only be used when the local device's role is master.
However, Volume 3, Part A, 4.20 and 4.21 state that the request must
be initiated on the Slave side and the response must be initiated on
the Master (the 0x0013 hints that lecup is sending a response, but I
may be mistaken). I may be getting confused with terms, so I'll just
ask:

How do I initiate a Connection Update from the peripheral? If this
isn't possible, how to I dictate the connection parameters (the
current connection is much too slow)?

Thanks,
Sandy

-- 

Re: LE Connection Update Disallowed

[Anderson Lizardo]

Hi Sandy,

On Wed, Feb 5, 2014 at 8:26 AM, Sandy Chapman <schapman@lixar.com> wrote:
> I establish an LE connection between the devices. The central
> successfully discovers the services and characteristics and can read
> them. Once the connection is established, I run this command on the
> Linux peripheral:
>
> $ sudo ./bin/hcitool lecup --handle 64 --min 24 --max 50 --latency 4
> --timeout 550
>>>> Could not change connection params: Input/output error(5)
>
> In my hcidump -X, I get this:
>
> < HCI Command: LE Connection Update (0x08|0x0013) plen 14
>   0000: 40 00 18 00 32 00 04 00  26 02 01 00 01 00        @...2...&.....
>> HCI Event: Command Status (0x0f) plen 4
>     LE Connection Update (0x08|0x0013) status 0x0c ncmd 1
>     Error: Command Disallowed

This errors comes directly from the controller. The host is not at
fault here, as hcitool issues HCI commands directly to the controller.

> 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.

> If this
> isn't possible, how to I dictate the connection parameters (the
> current connection is much too slow)?

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.

Best Regards,
-- 
Anderson Lizardo
http://www.indt.org/?lang=en
INdT - Manaus - Brazil

Re: LE Connection Update Disallowed

[Sandy Chapman]

Hi Anderson,

On Wed, Feb 5, 2014 at 9:12 AM, Anderson Lizardo
<anderson.lizardo@openbossa.org> wrote:
> Hi Sandy,
>
> On Wed, Feb 5, 2014 at 8:26 AM, Sandy Chapman <schapman@lixar.com> wrote:
>> I establish an LE connection between the devices. The central
>> successfully discovers the services and characteristics and can read
>> them. Once the connection is established, I run this command on the
>> Linux peripheral:
>>
>> $ sudo ./bin/hcitool lecup --handle 64 --min 24 --max 50 --latency 4
>> --timeout 550
>>>>> Could not change connection params: Input/output error(5)
>>
>> In my hcidump -X, I get this:
>>
>> < HCI Command: LE Connection Update (0x08|0x0013) plen 14
>>   0000: 40 00 18 00 32 00 04 00  26 02 01 00 01 00        @...2...&.....
>>> HCI Event: Command Status (0x0f) plen 4
>>     LE Connection Update (0x08|0x0013) status 0x0c ncmd 1
>>     Error: Command Disallowed
>
> This errors comes directly from the controller. The host is not at
> fault here, as hcitool issues HCI commands directly to the controller.
>
>> 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'.

$ hcitool con
<<< Connections:
<<< Unknown 53:DC:05:A5:FA:7B handle 64 state 1 lm SLAVE

>
>> If this
>> isn't possible, how to I dictate the connection parameters (the
>> current connection is much too slow)?
>
> 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).

>
> Best Regards,
> --
> Anderson Lizardo
> http://www.indt.org/?lang=en
> INdT - Manaus - Brazil

Now what I want to do is to issue a command to the controller to begin
the Connection Update. This would result in the linux slave issuing a
Connection Update packet to the iPhone master. This doesn't seem to be
happening and is being blocked.

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?

Thanks again,
Sandy

-- 

Re: LE Connection Update Disallowed

[Anderson Lizardo]

HI Sandy,

On Wed, Feb 5, 2014 at 10:51 AM, Sandy Chapman <schapman@lixar.com> 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)

>> 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).

Best Regards,
-- 
Anderson Lizardo
http://www.indt.org/?lang=en
INdT - Manaus - Brazil

Re: LE Connection Update Disallowed

[Sandy Chapman]

Hi Anderson,

On Wed, Feb 5, 2014 at 11:23 AM, Anderson Lizardo
<anderson.lizardo@openbossa.org> wrote:
> HI Sandy,
>
> On Wed, Feb 5, 2014 at 10:51 AM, Sandy Chapman <schapman@lixar.com> 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

-- 

Re: LE Connection Update Disallowed

[Sandy Chapman]

Hi All,

On Thu, Feb 6, 2014 at 12:21 PM, Sandy Chapman <schapman@lixar.com> wrote:
> Hi Anderson,
>
> On Wed, Feb 5, 2014 at 11:23 AM, Anderson Lizardo
> <anderson.lizardo@openbossa.org> wrote:
>> HI Sandy,
>>
>> On Wed, Feb 5, 2014 at 10:51 AM, Sandy Chapman <schapman@lixar.com> 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

-- 

Re: LE Connection Update Disallowed

[Jan Rüth]

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