AW: Bluetooth: Is it possible to operate Bluez concurrent in central and peripheral role?

[Eisenkolb Thomas <Eisenkolb.Thomas@fronius.com>]

> Hi Thomas,
>
> On Fri, Oct 12, 2018 at 10:36 AM Eisenkolb Thomas <Eisenkolb.Thomas@fronius.com> wrote:
> >
> > Hello,
> >
> > Thanks for the answer.
> >
> > I have recorded logs of the exact use cases which I have to realize.
> >
> > The following MAC-Addresses of the devices are important:
> >         - Embedded Linux device: "78-C4-0E-80-07-CD"
> >         - Smartphone: "4C-D6-A9-48-CA-0C"
> >         - Sensor device: "88-6B-0F-94-C2-38"
> >
> > I wanted to shorten the logs that no information gets lost.
> >
> > To produce this log I did the following operations in chronological order:
> >         1) start btmgt tool (embedded linux)
>
> You shouldn't need to btmgmt for these use cases, bluetoothctl can manage advertisements.

Thanks for the hint. I just started btmgmt to get detailed information about my system in the btmon log.

>
> >         2) call btmgt info (embedded linux)
> >         3) Register advertising instances (embedded linux as peripheral)
> >         4) Scan for advertising devices (Smartphone as central)
> >         5) Stop scan for advertising devices(Smartphone as central)
> >         6) Connect to embedded linux device (Smartphone as central)
> >         -> established
> >         7) Start scan for advertising devices(embedded linux as central)
> >         8) Stop scan for advertising devices(embedded linux as central)
> >         9) Connect to sensor(embedded linux as central)
> >         -> Failed
>
> I don't see the connection request, perhaps it doesn't happen because we never found it while scanning? Does the connection timeout?
>

Bluetoothctl.log:
The Sensor device is found while scanning. It in line 78.
The connection attempt is visible in the same log in line 103 and also the error that occurred in line 105.

In btmon.log the device was first time discovered at line 3451 and then every 1/2 second.
Discovery gets disabled at line 11824.
After that there should be the connection attempt hci command as it can be seen in Bluetoothctl.log.
In line 11885 the used device is added to the whitelist which seems to success.(At this place I expected to get an connection attempt)

As you said this is strange because no connection attempt reaches the hci interface.

> >         10) Disconnect from embedded Linux(Smartphone as central)
This MGMT Event is at line 12587. The smartphone successfully disconnected from the embedded linux device.

> >         11) Connect to sensor(embedded linux as central)
> >         -> established
The successful connection event to the sensor is at line 12735.

> >         12) Connect to embedded linux device(Smartphone as central)
> >         -> failed
> >         13) Tray again connect to embedded linux device(Smartphone as central)
> >         -> failed
>
> Same thing here, perhaps bluetoothd logs would tell why it has failed.

Yes this is also strange.
For this I will have a look at the bluetoothd logs.

>
> >
> > There are three log files in the attachments which have been recorded concurrent.
> > One from "btmgt", "bluetoothctl" and "btmon".
>
> Don't mix btmgmt with bluetoothd, btmgmt is more of a debug tool for testing the kernel interface directly instead of using D-Bus but using both is not recommended.

Thanks for the hint. For future I will just use bluetoothctl.

>
> > As you will see in the logs from the sight of the embedded device I was just able to establish one connection concurrent.
> > Whether peripheral connection or a central connection but not both at the same time.
>
> I see a lot of reports which means we are scanning but it looks like there is never a connection attempt, except for the ones that does succeed.

I fully agree. I just see the attempt in the logs of bluetoothctl but no attempt reaches the hci interface.
Is it in general from the blueZ side possible to have a central and a peripheral connection opened parallel at the same time?
I just get more than one connections to peripherals at the same time and this works fine.

>
> > If the embedded device acts just as central device, it is possible to establish more connections to different sensors at the same time.
>
> That is really weird because the only difference is that you would not be advertising, this could be a problem with the controller though, have you tried any other controller to see if it has the same behaviour?

Actually I am using the SPB209A Module from HD Wireless. 
I don't have any other module that supports Bluetooth >= 4.1(As I found this is the minimum required standard that supports concurrent BLE roles) 

>
> > Thanks for your help.
> >
> > Best Regards,
> > Thomas
> >
> > Hi Thomas,
> > On Thu, Oct 11, 2018 at 10:18 AM Eisenkolb Thomas <Eisenkolb.Thomas@fronius.com> wrote:
> > >
> > > Hello,
> > >
> > > I am working with blueZ 5.50 on a linux embedded device with kernel 4.14.
> > >
> > > Now I have to implement a use case where the linux embedded device communicates as a central device with a few sensors through Bluetooth LE characteristics and at the same time it should advertise some data and accept at least one incoming connection from a Smartphone as a peripheral device for maintenance cases.
> > >
> > > I haven't found any information about blueZ is supporting both LE roles at the same time.
> > > I have already tried it now for 2 days to get this use case to work and I found a few limitations for which I didn't find any solution.
> > >
> > > I was not able to advertise any data while my device had an active connection to a peripheral device.
> > > Also while the Smartphone is connected to my embedded device(peripheral), I don't receive any advertised Data from any sensor and I cannot connect to any sensor.
> > >
> > > The Bluetooth Hardware Module which I am using on the embedded Linux System supports Bluetooth 4.2. From the Bluetooth Standard I have found that concurrent use of both Bluetooth Low Energy Roles should be supported since Bluetooth 4.1.
> > >
> > > Is it possible from blueZ Stack side to implement this use-case?
> >
> > BlueZ should work as dual roles already, if it doesn't there could bugs or the controller preventing commands to work properly.
> >
> > > If yes, can you give me some hints what I have to consider to get this case working?
> >
> > Do you have HCI logs of the problem(s)?
> >
> > > If no, have you got a timeline when it will be supported or is this no planned to implement in near future?
> >
> > Most of upstream effort is on mesh and updates to include 5.0 features, but dual-role is something that we might consider high priority if that is not working properly.
> >
> > >
> > > Thanks for your answer,
> > > Thomas
> > >
> > >
> >
> >
> > --
> > Luiz Augusto von Dentz
>
>
>
> --
> Luiz Augusto von Dentz

Best Regards,
Thomas Eisenkolb