Hello all,
Summary:
I am attempting to reconnect to a BLE glucometer with gatttool after pairing
with bluetoothctl. A quick connection update seems to cause a large delay
(around a minute) in the transmission of the LL_ENC_REQ.
Description:
Attempting to connect to an agent which after connecting immediately sends
an L2CAP update connection parameters request with minimum connection
interval set to 20 ms, and maximum connection interval set to 40 ms.
Increasing both values by 100 ms causes the problem to stop being generated.
The problem happens only if the dongle using the Broadcom BCM20702 chipset
is used, using a CSR8510 A10 dongle I cannot generate this issue. I am using
BlueZ 5.22, using Linux kernel 3.10.17. The hardware platform is a Utilite.
Caleb Reinhold
Hi Marcel,
>>>> I am attempting to reconnect to a BLE glucometer with gatttool after
>>>> pairing with bluetoothctl. A quick connection update seems to cause a
>>>> large delay (around a minute) in the transmission of the LL_ENC_REQ.
>>>>
>>>> Description:
>>>> Attempting to connect to an agent which after connecting immediately
>>>> sends an L2CAP update connection parameters request with minimum
>>>> connection interval set to 20 ms, and maximum connection interval set to
>> 40 ms.
>>>> Increasing both values by 100 ms causes the problem to stop being
>> generated.
>>>> The problem happens only if the dongle using the Broadcom BCM20702
>>>> chipset is used, using a CSR8510 A10 dongle I cannot generate this
>>>> issue. I am using BlueZ 5.22, using Linux kernel 3.10.17. The hardware
>> platform is a Utilite.
>>> try using a 3.17-rc3 kernel. We added storing of the connection parameters.
>> New connections
>>> will then use the previously requested connection parameters when
>> establishing the connection.
>>> Which means the peripheral does not have to request connection updates on
>> every connection.
>>
>> According to the HCI dump I am not using the saved parameters. I see the
>> updated parameters getting saved, but the outgoing connection appears to not
>> be using them.
> if you run btmon, do you see a mgmt command that indicates that the parameters are actually send to userspace. I think at the moment, we only really store the parameters for devices that are a) in our device list or b) we have paired with.
>
We do see this command in btmon, right after the connection update. The
parameters also appear to be written to /var/lib/bluetooth/.../.../info.
Regards,
Tom Harada
Hi Caleb,
>>> I am attempting to reconnect to a BLE glucometer with gatttool after
>>> pairing with bluetoothctl. A quick connection update seems to cause a
>>> large delay (around a minute) in the transmission of the LL_ENC_REQ.
>>>
>>> Description:
>>> Attempting to connect to an agent which after connecting immediately
>>> sends an L2CAP update connection parameters request with minimum
>>> connection interval set to 20 ms, and maximum connection interval set to
> 40 ms.
>>> Increasing both values by 100 ms causes the problem to stop being
> generated.
>>>
>>> The problem happens only if the dongle using the Broadcom BCM20702
>>> chipset is used, using a CSR8510 A10 dongle I cannot generate this
>>> issue. I am using BlueZ 5.22, using Linux kernel 3.10.17. The hardware
> platform is a Utilite.
>>
>> try using a 3.17-rc3 kernel. We added storing of the connection parameters.
> New connections
>> will then use the previously requested connection parameters when
> establishing the connection.
>> Which means the peripheral does not have to request connection updates on
> every connection.
>
> According to the HCI dump I am not using the saved parameters. I see the
> updated parameters getting saved, but the outgoing connection appears to not
> be using them.
if you run btmon, do you see a mgmt command that indicates that the parameters are actually send to userspace. I think at the moment, we only really store the parameters for devices that are a) in our device list or b) we have paired with.
Regards
Marcel
Hi Marcel
>> I am attempting to reconnect to a BLE glucometer with gatttool after
>> pairing with bluetoothctl. A quick connection update seems to cause a
>> large delay (around a minute) in the transmission of the LL_ENC_REQ.
>>
>> Description:
>> Attempting to connect to an agent which after connecting immediately
>> sends an L2CAP update connection parameters request with minimum
>> connection interval set to 20 ms, and maximum connection interval set to
40 ms.
>> Increasing both values by 100 ms causes the problem to stop being
generated.
>>
>> The problem happens only if the dongle using the Broadcom BCM20702
>> chipset is used, using a CSR8510 A10 dongle I cannot generate this
>> issue. I am using BlueZ 5.22, using Linux kernel 3.10.17. The hardware
platform is a Utilite.
>
>try using a 3.17-rc3 kernel. We added storing of the connection parameters.
New connections
>will then use the previously requested connection parameters when
establishing the connection.
>Which means the peripheral does not have to request connection updates on
every connection.
According to the HCI dump I am not using the saved parameters. I see the
updated parameters getting saved, but the outgoing connection appears to not
be using them.
Regards
Caleb Reinhold
Hi Caleb,
> I am attempting to reconnect to a BLE glucometer with gatttool after pairing
> with bluetoothctl. A quick connection update seems to cause a large delay
> (around a minute) in the transmission of the LL_ENC_REQ.
>
> Description:
> Attempting to connect to an agent which after connecting immediately sends
> an L2CAP update connection parameters request with minimum connection
> interval set to 20 ms, and maximum connection interval set to 40 ms.
> Increasing both values by 100 ms causes the problem to stop being generated.
>
> The problem happens only if the dongle using the Broadcom BCM20702 chipset
> is used, using a CSR8510 A10 dongle I cannot generate this issue. I am using
> BlueZ 5.22, using Linux kernel 3.10.17. The hardware platform is a Utilite.
try using a 3.17-rc3 kernel. We added storing of the connection parameters. New connections will then use the previously requested connection parameters when establishing the connection. Which means the peripheral does not have to request connection updates on every connection.
Regards
Marcel