bt dongle goes awry after too many connections

bt dongle goes awry after too many connections

[Tim Tisdall]

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

Re: bt dongle goes awry after too many connections

[Marcel Holtmann]

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

Re: bt dongle goes awry after too many connections

[Tim Tisdall]

On Mon, Mar 2, 2015 at 7:17 PM, Marcel Holtmann <marcel@holtmann.org> 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

Re: bt dongle goes awry after too many connections

[Tim Tisdall]

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.

Re: bt dongle goes awry after too many connections

[Marcel Holtmann]

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

Re: bt dongle goes awry after too many connections

[Tim Tisdall]

On Tue, Mar 3, 2015 at 11:19 AM, Marcel Holtmann <marcel@holtmann.org> 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.

Re: bt dongle goes awry after too many connections

[Tim Tisdall]

On Tue, Mar 3, 2015 at 11:19 AM, Marcel Holtmann <marcel@holtmann.org> 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?

Re: bt dongle goes awry after too many connections

[Andrejs Hanins]

Hi,
On 2015.03.09. 16:40, Tim Tisdall wrote:
> On Tue, Mar 3, 2015 at 11:19 AM, Marcel Holtmann <marcel@holtmann.org> 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 majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: bt dongle goes awry after too many connections

[Marcel Holtmann]

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

Re: bt dongle goes awry after too many connections

[Andrejs Hanins]

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 daemon@3.19.x 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
>

Re: bt dongle goes awry after too many connections

[Tim Tisdall]

On Mon, Mar 9, 2015 at 12:47 PM, Andrejs Hanins <andrejs.hanins@ubnt.com> wrote:
> Sure, I noticed that lots of work has been done lately in regard to LE, so
> I'm indeed using 5.28 daemon@3.19.x 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.

Re: bt dongle goes awry after too many connections

[Andrejs Hanins]

On 2015.03.09. 18:53, Tim Tisdall wrote:
> On Mon, Mar 9, 2015 at 12:47 PM, Andrejs Hanins <andrejs.hanins@ubnt.com> wrote:
>> Sure, I noticed that lots of work has been done lately in regard to LE, so
>> I'm indeed using 5.28 daemon@3.19.x 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.

Re: bt dongle goes awry after too many connections

[Marcel Holtmann]

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 daemon@3.19.x 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

Re: bt dongle goes awry after too many connections

[Andrejs Hanins]

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 daemon@3.19.x 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
>

RE: bt dongle goes awry after too many connections

[Tim Tisdall]

Sorry, the error I mentioned is called HCI_MAX_NUMBER_OF_CONNECTIONS
in the Bluez bluetooth.h file.  The name I gave it is from the
Bluetooth specs (CONNECTION_LIMIT_EXCEEDED).

- Tim