I have a "0a5c:21e8 Broadcom Corp. BCM20702A0 Bluetooth 4.0" usb
bluetooth dongle I'm using to connect to multiple BLE devices. It
used to be that I could connect to 7 devices with no issues and then
when I tried to connect to the 8th device I'd get a
CONNECTION_LIMIT_EXCEEDED error. In my code I would then tag that
dongle as having a connection limit of 7 and limit the number of
connections.
Recently I was using this code and found that it no longer works. The
dongle seems to "successfully" connect to ~13 devices but things don't
work properly. At least half of the devices no longer respond to GATT
commands sent to it. I issue a GATT command after connecting to each
device to read some attributes and most simply do nothing (no error,
no response, nothing).
Any way, I'm not really familiar with how things are laid out in the
kernel so I'm not really sure where that CONNECTION_LIMIT_EXCEEDED was
being created before and why it's no longer working as expected. I
tried looking through the git logs in "btusb" and "bluetooth" modules
and didn't really see anything pertinent.
-Tim
Marcel,
On 2015.03.09. 19:10, Marcel Holtmann wrote:
> Hi Andrejs,
>
>>>>>> If you do not need BR/EDR, you can switch that off and it might free the radio resources you need for the many LE connections.
>>>>> Would someone please tell me how you do that? I haven't seen this
>>>>> being done before. Is it an HCI command? ioctl command to the
>>>>> kernel?
>>>> ControllerMode = le
>>>> in /etc/bluetooth/main.conf
>>> which might at least need a 3.13.x kernel to actually work correctly. While the API is there, we have made significant fixes to the LE only mode in later kernels. Using a dual-mode controller in LE only mode actually needed some extra care.
>>>
>>> As I said, if it is not 3.18.x or 3.19.x kernel, then personally I would not bet on it. We have made sure that bug fixes are put into the -stable kernels for these release. Anything older has no guarantee anymore.
>> Sure, I noticed that lots of work has been done lately in regard to LE, so I'm indeed using 5.28 [email protected] kernel in LE-only mode and so far so good.
>> One of the useful things which still seems to be missing is the control over LE advertisements via D-Bus iface. "Discoverable" property change does not affect LE advs. I'm currently using 'hciconfig hci0 leadv' to make it work. But still, LE advs stop and do not re-start after adapter is connected/disconnected to some peripheral.
> you might want to try "btmgmt advertising on" instead. It will toggle the connectable and discoverable settings accordingly.
>
> You also really want the kernel take control over advertising. Otherwise you have to keep re-enabling after each connection. The controller will turn it off once a connection has been created. The kernel does take care of that for you if you use the mgmt interface.
Oh, thank you! It really works now as it should. For some reason, it
didn't work for me when I tried it an hour ago :)
>
> Regards
>
> Marcel
>
Hi Andrejs,
>>>>> If you do not need BR/EDR, you can switch that off and it might free the radio resources you need for the many LE connections.
>>>> Would someone please tell me how you do that? I haven't seen this
>>>> being done before. Is it an HCI command? ioctl command to the
>>>> kernel?
>>> ControllerMode = le
>>> in /etc/bluetooth/main.conf
>> which might at least need a 3.13.x kernel to actually work correctly. While the API is there, we have made significant fixes to the LE only mode in later kernels. Using a dual-mode controller in LE only mode actually needed some extra care.
>>
>> As I said, if it is not 3.18.x or 3.19.x kernel, then personally I would not bet on it. We have made sure that bug fixes are put into the -stable kernels for these release. Anything older has no guarantee anymore.
> Sure, I noticed that lots of work has been done lately in regard to LE, so I'm indeed using 5.28 [email protected] kernel in LE-only mode and so far so good.
> One of the useful things which still seems to be missing is the control over LE advertisements via D-Bus iface. "Discoverable" property change does not affect LE advs. I'm currently using 'hciconfig hci0 leadv' to make it work. But still, LE advs stop and do not re-start after adapter is connected/disconnected to some peripheral.
you might want to try "btmgmt advertising on" instead. It will toggle the connectable and discoverable settings accordingly.
You also really want the kernel take control over advertising. Otherwise you have to keep re-enabling after each connection. The controller will turn it off once a connection has been created. The kernel does take care of that for you if you use the mgmt interface.
Regards
Marcel
On 2015.03.09. 18:53, Tim Tisdall wrote:
> On Mon, Mar 9, 2015 at 12:47 PM, Andrejs Hanins <[email protected]> wrote:
>> Sure, I noticed that lots of work has been done lately in regard to LE, so
>> I'm indeed using 5.28 [email protected] kernel in LE-only mode and so far so
>> good.
>> One of the useful things which still seems to be missing is the control over
>> LE advertisements via D-Bus iface. "Discoverable" property change does not
>> affect LE advs. I'm currently using 'hciconfig hci0 leadv' to make it work.
>> But still, LE advs stop and do not re-start after adapter is
>> connected/disconnected to some peripheral.
> It's doing what I'd expect then... I expect dongles to be reset if
> they're unplugged and then re-attached. I don't know if there's an
> expectation for devices to be returned to their last state if they're
> disconnected and re-connected when using DBUS, though.
I didn't mean physically re-plugging the adapter. LE advs stop when
adapter (controlled via D-Bus) is connected to some other device and
does not start again when connection is closed. The adapter itself stays
as it is.
> I've pretty
> much avoided the DBUS interface since most of what I'm doing is simply
> not possible through it.
On Mon, Mar 9, 2015 at 12:47 PM, Andrejs Hanins <[email protected]> wrote:
> Sure, I noticed that lots of work has been done lately in regard to LE, so
> I'm indeed using 5.28 [email protected] kernel in LE-only mode and so far so
> good.
> One of the useful things which still seems to be missing is the control over
> LE advertisements via D-Bus iface. "Discoverable" property change does not
> affect LE advs. I'm currently using 'hciconfig hci0 leadv' to make it work.
> But still, LE advs stop and do not re-start after adapter is
> connected/disconnected to some peripheral.
It's doing what I'd expect then... I expect dongles to be reset if
they're unplugged and then re-attached. I don't know if there's an
expectation for devices to be returned to their last state if they're
disconnected and re-connected when using DBUS, though. I've pretty
much avoided the DBUS interface since most of what I'm doing is simply
not possible through it.
Hi Marcel,
On 2015.03.09. 18:21, Marcel Holtmann wrote:
> Hi Andrejs,
>
>>>> If you do not need BR/EDR, you can switch that off and it might free the radio resources you need for the many LE connections.
>>> Would someone please tell me how you do that? I haven't seen this
>>> being done before. Is it an HCI command? ioctl command to the
>>> kernel?
>> ControllerMode = le
>> in /etc/bluetooth/main.conf
> which might at least need a 3.13.x kernel to actually work correctly. While the API is there, we have made significant fixes to the LE only mode in later kernels. Using a dual-mode controller in LE only mode actually needed some extra care.
>
> As I said, if it is not 3.18.x or 3.19.x kernel, then personally I would not bet on it. We have made sure that bug fixes are put into the -stable kernels for these release. Anything older has no guarantee anymore.
Sure, I noticed that lots of work has been done lately in regard to LE,
so I'm indeed using 5.28 [email protected] kernel in LE-only mode and so far
so good.
One of the useful things which still seems to be missing is the control
over LE advertisements via D-Bus iface. "Discoverable" property change
does not affect LE advs. I'm currently using 'hciconfig hci0 leadv' to
make it work. But still, LE advs stop and do not re-start after adapter
is connected/disconnected to some peripheral.
>
> Regards
>
> Marcel
>
Hi Andrejs,
>>> If you do not need BR/EDR, you can switch that off and it might free the radio resources you need for the many LE connections.
>> Would someone please tell me how you do that? I haven't seen this
>> being done before. Is it an HCI command? ioctl command to the
>> kernel?
> ControllerMode = le
> in /etc/bluetooth/main.conf
which might at least need a 3.13.x kernel to actually work correctly. While the API is there, we have made significant fixes to the LE only mode in later kernels. Using a dual-mode controller in LE only mode actually needed some extra care.
As I said, if it is not 3.18.x or 3.19.x kernel, then personally I would not bet on it. We have made sure that bug fixes are put into the -stable kernels for these release. Anything older has no guarantee anymore.
Regards
Marcel
Hi,
On 2015.03.09. 16:40, Tim Tisdall wrote:
> On Tue, Mar 3, 2015 at 11:19 AM, Marcel Holtmann <[email protected]> wrote:
>> If you do not need BR/EDR, you can switch that off and it might free the radio resources you need for the many LE connections.
> Would someone please tell me how you do that? I haven't seen this
> being done before. Is it an HCI command? ioctl command to the
> kernel?
ControllerMode = le
in /etc/bluetooth/main.conf
> --
> To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, Mar 3, 2015 at 11:19 AM, Marcel Holtmann <[email protected]> wrote:
> If you do not need BR/EDR, you can switch that off and it might free the radio resources you need for the many LE connections.
Would someone please tell me how you do that? I haven't seen this
being done before. Is it an HCI command? ioctl command to the
kernel?
On Tue, Mar 3, 2015 at 11:19 AM, Marcel Holtmann <[email protected]> wrot=
e:
> it is only btusb talking to the hardware. In the end it is just a transpo=
rt layer. The real work happens in the Bluetooth core. However that said, w=
e never had a limit on number of LE connections. Nothing there was ever enf=
orced.
I was afraid of that... I guess that means that there must be
different versions of the dongle. We're working with many devices and
ordered many dongles over the last 2 years. It's possible the
manufacturer slipped in some changes over that time. I'll see if I
can confirm that.
> If you do not need BR/EDR, you can switch that off and it might free the =
radio resources you need for the many LE connections. However a 3.13 is not=
really getting you there. It might actually work there, but I would only t=
rust a 3.18 or 3.19 kernel here.
Yeah, it's be nice if everyone was on mainline, but unfortunately I'm
stuck using 3.4 for the embedded device I'm using. How do I shut off
the BR/EDR aspects of the dongle? I'm not sure if it'd help, but it's
worth trying.
Hi Tim,
>>> I have a "0a5c:21e8 Broadcom Corp.BCM20702A0 Bluetooth 4.0" usb
>>
>> have to tried to install the firmware for the Broadcom dongle. It could be well that the firmware update fixes a few of these bugs with the LE connection behavior.
>>
>> You can grab the firmware file from the Windows driver and use the hex2hcd utility to convert it into a format that the btusb.ko kernel driver understands.
>
> We're not using the firmware and weren't using it before either. Is
> it possible there was some hack in place to prevent connecting to more
> than 7 sensors and some update has removed that? I couldn't find
> anything in "btusb" or "bluetooth" module git logs, though.
>
> Unfortunately, the kernel I'm having to use on my machine doesn't have
> the changes in btusb where it loads the Broadcom firmware for my
> device. However, I just tried my code out on another machine with a
> newer kernel (3.13 ubuntu 14.04) AND used the firmware and got the
> same result, so I don't think the firmware would help in this
> situation.
>
> Without the firmware, the only "driver" that's used by the dongle is
> btusb, right? Or is that some sort of abstraction layer for something
> else (a driver that doesn't care if it's usb, pci, etc)?
it is only btusb talking to the hardware. In the end it is just a transport layer. The real work happens in the Bluetooth core. However that said, we never had a limit on number of LE connections. Nothing there was ever enforced.
If you do not need BR/EDR, you can switch that off and it might free the radio resources you need for the many LE connections. However a 3.13 is not really getting you there. It might actually work there, but I would only trust a 3.18 or 3.19 kernel here.
Regards
Marcel
One other note, I have messages in my logs saying "Bluetooth: hci0 urb
[random code] failed to resubmit". I've seen these for a very long
time and have largely ignored them because I haven't been able to find
any details about it online. I still have no idea if it's pertinent,
but thought I'd mention it in case it's useful.
On Mon, Mar 2, 2015 at 7:17 PM, Marcel Holtmann <[email protected]> wrote:
> Hi Tim,
>
>> I have a "0a5c:21e8 Broadcom Corp.BCM20702A0 Bluetooth 4.0" usb
>
> have to tried to install the firmware for the Broadcom dongle. It could be well that the firmware update fixes a few of these bugs with the LE connection behavior.
>
> You can grab the firmware file from the Windows driver and use the hex2hcd utility to convert it into a format that the btusb.ko kernel driver understands.
We're not using the firmware and weren't using it before either. Is
it possible there was some hack in place to prevent connecting to more
than 7 sensors and some update has removed that? I couldn't find
anything in "btusb" or "bluetooth" module git logs, though.
Unfortunately, the kernel I'm having to use on my machine doesn't have
the changes in btusb where it loads the Broadcom firmware for my
device. However, I just tried my code out on another machine with a
newer kernel (3.13 ubuntu 14.04) AND used the firmware and got the
same result, so I don't think the firmware would help in this
situation.
Without the firmware, the only "driver" that's used by the dongle is
btusb, right? Or is that some sort of abstraction layer for something
else (a driver that doesn't care if it's usb, pci, etc)?
-Tim
Hi Tim,
> I have a "0a5c:21e8 Broadcom Corp.BCM20702A0 Bluetooth 4.0" usb
> bluetooth dongle I'm using to connect to multiple BLE devices. It
> used to be that I could connect to 7 devices with no issues and then
> when I tried to connect to the 8th device I'd get a
> CONNECTION_LIMIT_EXCEEDED error. In my code I would then tag that
> dongle as having a connection limit of 7 and limit the number of
> connections.
>
> Recently I was using this code and found that it no longer works. The
> dongle seems to "successfully" connect to ~13 devices but things don't
> work properly. At least half of the devices no longer respond to GATT
> commands sent to it. I issue a GATT command after connecting to each
> device to read some attributes and most simply do nothing (no error,
> no response, nothing).
>
> Any way, I'm not really familiar with how things are laid out in the
> kernel so I'm not really sure where that CONNECTION_LIMIT_EXCEEDED was
> being created before and why it's no longer working as expected. I
> tried looking through the git logs in "btusb" and "bluetooth" modules
> and didn't really see anything pertinent.
have to tried to install the firmware for the Broadcom dongle. It could be well that the firmware update fixes a few of these bugs with the LE connection behavior.
You can grab the firmware file from the Windows driver and use the hex2hcd utility to convert it into a format that the btusb.ko kernel driver understands.
Regards
Marcel