Re: Operating central and peripheral roles concurrently

[Luiz Augusto von Dentz <luiz.dentz@gmail.com>]

Hi Martin,
On Fri, Nov 9, 2018 at 7:57 PM Martin Townsend <mtownsend1973@gmail.com> wrote:
>
> On Fri, Nov 9, 2018 at 4:32 PM Martin Townsend <mtownsend1973@gmail.com> wrote:
> >
> > Hi,
> >
> > I see someone has already asked this question not long ago but I am
> > seeing the same problem.  I have an embedded platform running 4.9
> > kernel and Bluez 5.50 and the bluetooth device is the BroadCom
> > BCM4343W which supports bluetooth 4.1.
> >
> > I can run the btgatt-server and example-gatt-server fine and connect
> > to it from my phone using nRF and read the relevant attributes.  This
> > I believe is where my device is in the peripheral role.  If I close
> > the GATT server down I can use gatttool to query the characteristics
> > of another GATT server setup on my PC, I think this is then acting as
> > central role.
> >
> > But if I can't do both at the same time, once the GATT server is
> > running and I try and query the other GATT server, I get
> > root@mach-cw-rnet-ppm-1717:~# gatttool -b 5D:3C:72:B5:23:BE -t random
> > --characteristics
> > connect error: Connection refused (111)
> >
> > I've noticed that if I start bluetoothctl whilst the GATT server is
> > running it looks as if it has connected to my phone
> >
> > root@mach-cw-rnet-ppm-1717:~# bluetoothctl
> > Agent registered
> > [LG K8 (2017)]#
> >
> > Maybe this is expected but it does look like it has made a connection
> > back to the phone and I'm wondering if this is stopping it from acting
> > in the central role?
> >
> > Not really knowing much about the bluetooth stack I was wondering if
> > anyone has any pointers on how to debug this or let me know if I'm
> > doing something wrong?  I'm quite comfortable putting debug code into
> > the kernel and/or bluez5 and recompiling to get more information if
> > required.
> >
> > Any help would be greatly appreciated,
> > Martin.
>
> I turned on DEBUG for a few of the hci_.c files and here's the output
> of the failed connect in case it helps
>
> These occur on connect from gatttool:
> Nov 09 08:03:00 mach-cw-rnet-ppm-1717 kernel: 00:00:00:00:00:00 ->
> 7b:bd:e7:6a:8a:8d
> Nov 09 08:03:00 mach-cw-rnet-ppm-1717 kernel: hci0 orig refcnt 9
> Nov 09 08:03:00 mach-cw-rnet-ppm-1717 kernel: requesting refresh of dst_addr
> Nov 09 08:03:00 mach-cw-rnet-ppm-1717 kernel: hci0 dst 7b:bd:e7:6a:8a:8d
> Nov 09 08:03:00 mach-cw-rnet-ppm-1717 kernel: hci0 orig refcnt 10
> Nov 09 08:03:00 mach-cw-rnet-ppm-1717 kernel: addr 7b:bd:e7:6a:8a:8d (type 1)
> Nov 09 08:03:00 mach-cw-rnet-ppm-1717 kernel: addr 7b:bd:e7:6a:8a:8d
> (type 1) auto_connect 5
> Nov 09 08:03:00 mach-cw-rnet-ppm-1717 kernel: hcon 97310400 orig refcnt 0
> Nov 09 08:03:00 mach-cw-rnet-ppm-1717 kernel: hci0 hcon 97310400
> Nov 09 08:03:00 mach-cw-rnet-ppm-1717 kernel: hci0 cmd_cnt 1 cmd queued 2
> Nov 09 08:03:00 mach-cw-rnet-ppm-1717 kernel: hci0 type 1 len 10
> Nov 09 08:03:00 mach-cw-rnet-ppm-1717 kernel: hci0
> Nov 09 08:03:00 mach-cw-rnet-ppm-1717 kernel: hci0 Event packet
> Nov 09 08:03:00 mach-cw-rnet-ppm-1717 kernel: hci0 opcode 0x200b
> Nov 09 08:03:00 mach-cw-rnet-ppm-1717 kernel: opcode 0x200b status 0x00
> Nov 09 08:03:00 mach-cw-rnet-ppm-1717 kernel: hci0 opcode 0x200b
> Nov 09 08:03:00 mach-cw-rnet-ppm-1717 kernel: hci0 cmd_cnt 1 cmd queued 1
> Nov 09 08:03:00 mach-cw-rnet-ppm-1717 kernel: hci0 type 1 len 5
> Nov 09 08:03:00 mach-cw-rnet-ppm-1717 kernel: hci0
> Nov 09 08:03:00 mach-cw-rnet-ppm-1717 kernel: hci0 Event packet
> Nov 09 08:03:00 mach-cw-rnet-ppm-1717 kernel: hci0 opcode 0x200c
> Nov 09 08:03:00 mach-cw-rnet-ppm-1717 kernel: opcode 0x200c status 0x00
> Nov 09 08:03:00 mach-cw-rnet-ppm-1717 kernel: hci0 opcode 0x200c
> Nov 09 08:03:00 mach-cw-rnet-ppm-1717 kernel: hci0
> Nov 09 08:03:00 mach-cw-rnet-ppm-1717 kernel: hci0 Event packet
>
>
> Then just before Error: connect error: Connection refused (111) many
> seconds later:
> Nov 09 08:03:41 mach-cw-rnet-ppm-1717 kernel: hcon 97310400 state BT_CONNECT
> Nov 09 08:03:41 mach-cw-rnet-ppm-1717 kernel: hci0 hcon 97310400
> Nov 09 08:03:41 mach-cw-rnet-ppm-1717 kernel: hci0 orig refcnt 10
> Nov 09 08:03:41 mach-cw-rnet-ppm-1717 kernel: hci0 hcon 97310400
> Nov 09 08:03:41 mach-cw-rnet-ppm-1717 kernel: addr 7b:bd:e7:6a:8a:8d (type 1)
> Nov 09 08:03:41 mach-cw-rnet-ppm-1717 kernel: hcon 97310400
> Nov 09 08:03:41 mach-cw-rnet-ppm-1717 kernel: hci0 hcon 97310400 chan 97421c80
> Nov 09 08:03:41 mach-cw-rnet-ppm-1717 kernel: hci0 orig refcnt 11
> Nov 09 08:03:41 mach-cw-rnet-ppm-1717 kernel: hci0 cmd_cnt 1 cmd queued 1
> Nov 09 08:03:41 mach-cw-rnet-ppm-1717 kernel: hci0 type 1 len 5
> Nov 09 08:03:41 mach-cw-rnet-ppm-1717 kernel: hci0 orig refcnt 10
> Nov 09 08:03:41 mach-cw-rnet-ppm-1717 kernel: hci0
> Nov 09 08:03:41 mach-cw-rnet-ppm-1717 kernel: hci0 Event packet
> Nov 09 08:03:41 mach-cw-rnet-ppm-1717 kernel: hci0 opcode 0x200c
> Nov 09 08:03:41 mach-cw-rnet-ppm-1717 kernel: opcode 0x200c status 0x00
> Nov 09 08:03:41 mach-cw-rnet-ppm-1717 kernel: hci0 opcode 0x200c

Not sure if it is exactly the same problem but you can try checking if
the following like is causing the problem:

https://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next.git/tree/net/bluetooth/hci_event.c#n5075

So we cannot be both slave and central, or at least that is what the
code suggests, though I think we should drop that line and leave the
controller to fail if that is the case.



-- 
Luiz Augusto von Dentz