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.
On Fri, Nov 9, 2018 at 4:32 PM Martin Townsend <[email protected]> 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
Regards, Martin.
Hi Martin,
On Fri, Nov 9, 2018 at 7:57 PM Martin Townsend <[email protected]> wrote:
>
> On Fri, Nov 9, 2018 at 4:32 PM Martin Townsend <[email protected]> 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
Hi,
On Sat, Nov 10, 2018 at 6:03 PM Luiz Augusto von Dentz
<[email protected]> wrote:
>
> Hi Martin,
> On Fri, Nov 9, 2018 at 7:57 PM Martin Townsend <[email protected]> wrote:
> >
> > On Fri, Nov 9, 2018 at 4:32 PM Martin Townsend <[email protected]> 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
Thanks for replying, just to confirm that this maybe the code to take a look at
/* Most controller will fail if we try to create new connections
* while we have an existing one in slave role.
*/
if (hdev->conn_hash.le_num_slave > 0)
return NULL;
If so, I'll put some debug code around it and try disabling it to see
if it makes a difference.
Regards, Martin.
Hi,
On Sat, Nov 10, 2018 at 6:29 PM Martin Townsend <[email protected]> wrote:
>
> Hi,
> On Sat, Nov 10, 2018 at 6:03 PM Luiz Augusto von Dentz
> <[email protected]> wrote:
> >
> > Hi Martin,
> > On Fri, Nov 9, 2018 at 7:57 PM Martin Townsend <[email protected]> wrote:
> > >
> > > On Fri, Nov 9, 2018 at 4:32 PM Martin Townsend <[email protected]> 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
>
> Thanks for replying, just to confirm that this maybe the code to take a look at
>
> /* Most controller will fail if we try to create new connections
> * while we have an existing one in slave role.
> */
> if (hdev->conn_hash.le_num_slave > 0)
> return NULL;
>
> If so, I'll put some debug code around it and try disabling it to see
> if it makes a difference.
>
> Regards, Martin.
I commented out those lines and put a debug print in to see if the
function was called and the function was only called when I initiated
a lescan to get the address of the GATT server I wanted to connect to
Nov 09 07:57:00 mach-cw-rnet-ppm-1717 kernel: hci0 Event packet
Nov 09 07:57:00 mach-cw-rnet-ppm-1717 kernel: check_pending_le_conn:
le_num_slave = 1
But when I tried to make the connection this function wasn't called at
all and it still failed even with the "if
(hdev->conn_hash.le_num_slave > 0) return NULL" commented out.
I'm starting to think that the chip doesn't support dual roles. With
all the debug turned on the first line I see when the connection fails
is
Nov 09 07:56:20 mach-cw-rnet-ppm-1717 kernel: hci_conn_timeout: hcon
972b0400 state BT_CONNECT
which seems to suggest it's timed out waiting from some response from
the HCI firmware on the bluetooth device? or am I wrong with this
assumption?
Where in the code could I put some debug to see that the connection
request is being passed to the HCI firmware layer?
any help greatly appreciated.
On Mon, Nov 12, 2018 at 1:52 PM Martin Townsend <[email protected]> wrote:
>
> Hi,
> On Sat, Nov 10, 2018 at 6:29 PM Martin Townsend <[email protected]> wrote:
> >
> > Hi,
> > On Sat, Nov 10, 2018 at 6:03 PM Luiz Augusto von Dentz
> > <[email protected]> wrote:
> > >
> > > Hi Martin,
> > > On Fri, Nov 9, 2018 at 7:57 PM Martin Townsend <[email protected]> wrote:
> > > >
> > > > On Fri, Nov 9, 2018 at 4:32 PM Martin Townsend <[email protected]> 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
> >
> > Thanks for replying, just to confirm that this maybe the code to take a look at
> >
> > /* Most controller will fail if we try to create new connections
> > * while we have an existing one in slave role.
> > */
> > if (hdev->conn_hash.le_num_slave > 0)
> > return NULL;
> >
> > If so, I'll put some debug code around it and try disabling it to see
> > if it makes a difference.
> >
> > Regards, Martin.
>
> I commented out those lines and put a debug print in to see if the
> function was called and the function was only called when I initiated
> a lescan to get the address of the GATT server I wanted to connect to
> Nov 09 07:57:00 mach-cw-rnet-ppm-1717 kernel: hci0 Event packet
> Nov 09 07:57:00 mach-cw-rnet-ppm-1717 kernel: check_pending_le_conn:
> le_num_slave = 1
>
> But when I tried to make the connection this function wasn't called at
> all and it still failed even with the "if
> (hdev->conn_hash.le_num_slave > 0) return NULL" commented out.
>
> I'm starting to think that the chip doesn't support dual roles. With
> all the debug turned on the first line I see when the connection fails
> is
> Nov 09 07:56:20 mach-cw-rnet-ppm-1717 kernel: hci_conn_timeout: hcon
> 972b0400 state BT_CONNECT
> which seems to suggest it's timed out waiting from some response from
> the HCI firmware on the bluetooth device? or am I wrong with this
> assumption?
>
> Where in the code could I put some debug to see that the connection
> request is being passed to the HCI firmware layer?
>
> any help greatly appreciated.
I've just been reading the 4.1 spec on GAP and on page 224 it states:
"In LE, GAP defines four specific roles: Broadcaster, Observer, Peripheral, and
Central. A device may support multiple LE GAP roles provided that the underly-
ing Controller supports those roles or role combinations. However, only one LE
GAP role may be supported at a given time. Each role specifies the require-
ments for the underlying Controller. This allows for Controllers to be optimized
for specific use cases."
Now to me that says a device can support being a central and
peripheral but doesn't have to support them concurrently so I'm
guessing if the device is in the peripheral role and then wanted to
connect to another device you would have to stop being a peripheral
(ie drop this connection) and then become a central, make the
connection and when finished disconnect and become a peripheral again
and wait for the other devices to reconnect to you. Or am I
mis-reading this?
Hi,
Den mån 12 nov. 2018 kl 17:19 skrev Martin Townsend <[email protected]>:
> I've just been reading the 4.1 spec on GAP and on page 224 it states:
>
>
> "In LE, GAP defines four specific roles: Broadcaster, Observer, Peripheral, and
> Central. A device may support multiple LE GAP roles provided that the underly-
> ing Controller supports those roles or role combinations. However, only one LE
> GAP role may be supported at a given time. Each role specifies the require-
> ments for the underlying Controller. This allows for Controllers to be optimized
> for specific use cases."
>
> Now to me that says a device can support being a central and
> peripheral but doesn't have to support them concurrently so I'm
> guessing if the device is in the peripheral role and then wanted to
> connect to another device you would have to stop being a peripheral
> (ie drop this connection) and then become a central, make the
> connection and when finished disconnect and become a peripheral again
> and wait for the other devices to reconnect to you. Or am I
> mis-reading this?
This restriction is lifted in newer versions of the spec. The same
section in version 4.2 says this:
"In LE, GAP defines four specific roles: Broadcaster, Observer, Peripheral, and
Central. A device may support multiple LE GAP roles provided that the
underlying Controller supports those roles or role combinations. Each role
specifies the requirements for the underlying Controller. This allows for
Controllers to be optimized for specific use cases."
If you use the btmon tool you can easily see what combination of
supported states the controller supports. If you have btmon running
while you initiate bluetoothd you will see the packet LE Read
Supported States Command, which contains this info.
Hi Emil, Martin,
On Tue, Nov 13, 2018 at 12:47 PM Emil Lenngren <[email protected]> wrote:
>
> Hi,
>
> Den mån 12 nov. 2018 kl 17:19 skrev Martin Townsend <[email protected]>:
> > I've just been reading the 4.1 spec on GAP and on page 224 it states:
> >
> >
> > "In LE, GAP defines four specific roles: Broadcaster, Observer, Peripheral, and
> > Central. A device may support multiple LE GAP roles provided that the underly-
> > ing Controller supports those roles or role combinations. However, only one LE
> > GAP role may be supported at a given time. Each role specifies the require-
> > ments for the underlying Controller. This allows for Controllers to be optimized
> > for specific use cases."
> >
> > Now to me that says a device can support being a central and
> > peripheral but doesn't have to support them concurrently so I'm
> > guessing if the device is in the peripheral role and then wanted to
> > connect to another device you would have to stop being a peripheral
> > (ie drop this connection) and then become a central, make the
> > connection and when finished disconnect and become a peripheral again
> > and wait for the other devices to reconnect to you. Or am I
> > mis-reading this?
>
> This restriction is lifted in newer versions of the spec. The same
> section in version 4.2 says this:
> "In LE, GAP defines four specific roles: Broadcaster, Observer, Peripheral, and
> Central. A device may support multiple LE GAP roles provided that the
> underlying Controller supports those roles or role combinations. Each role
> specifies the requirements for the underlying Controller. This allows for
> Controllers to be optimized for specific use cases."
>
> If you use the btmon tool you can easily see what combination of
> supported states the controller supports. If you have btmon running
> while you initiate bluetoothd you will see the packet LE Read
> Supported States Command, which contains this info.
In that case we should definitely use these states to determine
instead of assuming the controller don't support Master & Slave state,
though it would be great if Martin provides the HCI traces where it is
failing and if indeed is the controller not support it or some other
bug.
--
Luiz Augusto von Dentz
On Tue, Nov 13, 2018 at 11:21 AM Luiz Augusto von Dentz
<[email protected]> wrote:
>
> Hi Emil, Martin,
> On Tue, Nov 13, 2018 at 12:47 PM Emil Lenngren <[email protected]> wrote:
> >
> > Hi,
> >
> > Den mån 12 nov. 2018 kl 17:19 skrev Martin Townsend <[email protected]>:
> > > I've just been reading the 4.1 spec on GAP and on page 224 it states:
> > >
> > >
> > > "In LE, GAP defines four specific roles: Broadcaster, Observer, Peripheral, and
> > > Central. A device may support multiple LE GAP roles provided that the underly-
> > > ing Controller supports those roles or role combinations. However, only one LE
> > > GAP role may be supported at a given time. Each role specifies the require-
> > > ments for the underlying Controller. This allows for Controllers to be optimized
> > > for specific use cases."
> > >
> > > Now to me that says a device can support being a central and
> > > peripheral but doesn't have to support them concurrently so I'm
> > > guessing if the device is in the peripheral role and then wanted to
> > > connect to another device you would have to stop being a peripheral
> > > (ie drop this connection) and then become a central, make the
> > > connection and when finished disconnect and become a peripheral again
> > > and wait for the other devices to reconnect to you. Or am I
> > > mis-reading this?
> >
> > This restriction is lifted in newer versions of the spec. The same
> > section in version 4.2 says this:
> > "In LE, GAP defines four specific roles: Broadcaster, Observer, Peripheral, and
> > Central. A device may support multiple LE GAP roles provided that the
> > underlying Controller supports those roles or role combinations. Each role
> > specifies the requirements for the underlying Controller. This allows for
> > Controllers to be optimized for specific use cases."
> >
> > If you use the btmon tool you can easily see what combination of
> > supported states the controller supports. If you have btmon running
> > while you initiate bluetoothd you will see the packet LE Read
> > Supported States Command, which contains this info.
>
> In that case we should definitely use these states to determine
> instead of assuming the controller don't support Master & Slave state,
> though it would be great if Martin provides the HCI traces where it is
> failing and if indeed is the controller not support it or some other
> bug.
>
> --
> Luiz Augusto von Dentz
Apologies for the delay. I've heard back from the device manufacture
and they have confirmed that it does support both roles simultaneously
and have proved this using their WICED platform.
https://community.cypress.com/thread/36729
So I have ran btmon and then powered the device and get the following
LE Read Supported States message in the log (let me know if you want
the full log or other messages, there were quite a few of them)
< HCI Command: LE Read Supported States (0x08|0x001c) plen 0
#27 [hci0] 12.173109
> HCI Event: Command Complete (0x0e) plen 12 #28 [hci0] 12.178836
LE Read Supported States (0x08|0x001c) ncmd 1
Status: Success (0x00)
States: 0x000003ffffffffff
Non-connectable Advertising State
Scannable Advertising State
Connectable Advertising State
High Duty Cycle Directed Advertising State
Passive Scanning State
Active Scanning State
Initiating State
and Connection State (Master Role)
Connection State (Slave Role)
Non-connectable Advertising State
and Passive Scanning State
Scannable Advertising State
and Passive Scanning State
Connectable Advertising State
and Passive Scanning State
High Duty Cycle Directed Advertising State
and Passive Scanning State
Non-connectable Advertising State
and Active Scanning State
Scannable Advertising State
and Active Scanning State
Connectable Advertising State
and Active Scanning State
High Duty Cycle Directed Advertising State
and Active Scanning State
Non-connectable Advertising State
and Initiating State
Scannable Advertising State
and Initiating State
Non-connectable Advertising State
and Connection State (Master Role)
Scannable Advertising State
and Connection State (Master Role)
Non-connectable Advertising State
and Connection State (Slave Role)
Scannable Advertising State
and Connection State (Slave Role)
Passive Scanning State
and Initiating State
Active Scanning State
and Initiating State
Passive Scanning State
and Connection State (Master Role)
Active Scanning State
and Connection State (Master Role)
Passive Scanning State
and Connection State (Slave Role)
Active Scanning State
and Connection State (Slave Role)
Initiating State
and Connection State (Master Role)
and Master Role & Master Role
Low Duty Cycle Directed Advertising State
Low Duty Cycle Directed Advertising State
and Passive Scanning State
Low Duty Cycle Directed Advertising State
and Active Scanning State
Connectable Advertising State
and Initiating State
and Master Role & Slave Role
High Duty Cycle Directed Advertising State
and Initiating State
and Master Role & Slave Role
Low Duty Cycle Directed Advertising State
and Initiating State
and Master Role & Slave Role
Connectable Advertising State
and Connection State (Master Role)
and Master Role & Slave Role
High Duty Cycle Directed Advertising State
and Connection State (Master Role)
and Master Role & Slave Role
Low Duty Cycle Directed Advertising State
and Connection State (Master Role)
and Master Role & Slave Role
Connectable Advertising State
and Connection State (Slave Role)
and Master Role & Slave Role
High Duty Cycle Directed Advertising State
and Connection State (Slave Role)
and Slave Role & Slave Role
Low Duty Cycle Directed Advertising State
and Connection State (Slave Role)
and Slave Role & Slave Role
Initiating State
and Connection State (Slave Role)
and Master Role & Slave Role
Using btmon I then captured the HCI trace for the failing dual role case
Starting the GATT Server and connecting from a PC
========================================
< HCI Command: LE Set Advertising Parameters (0x08|0x0006) plen 15
#69 [hci0] 736.868434
Min advertising interval: 1280.000 msec (0x0800)
Max advertising interval: 1280.000 msec (0x0800)
Type: Connectable undirected - ADV_IND (0x00)
Own address type: Public (0x00)
Direct address type: Public (0x00)
Direct address: 00:00:00:00:00:00 (OUI 00-00-00)
Channel map: 37, 38, 39 (0x07)
Filter policy: Allow Scan Request from Any, Allow Connect
Request from Any (0x00)
> HCI Event: Command Complete (0x0e) plen 4 #70 [hci0] 736.875133
LE Set Advertising Parameters (0x08|0x0006) ncmd 1
Status: Success (0x00)
< HCI Command: LE Set Advertise Enable (0x08|0x000a) plen 1
#71 [hci0] 736.878291
Advertising: Enabled (0x01)
> HCI Event: Command Complete (0x0e) plen 4 #72 [hci0] 736.883585
LE Set Advertise Enable (0x08|0x000a) ncmd 1
Status: Success (0x00)
@ RAW Close: hciconfig
{0x0004} [hci0] 736.884982
@ RAW Close: hciconfig
{0x0003} 736.885139
@ RAW Open: btgatt-server (privileged) version 2.22
{0x0003} 736.950116
@ RAW Close: btgatt-server
{0x0003} 736.953288
@ RAW Open: btgatt-server (privileged) version 2.22
{0x0003} 736.953693
@ RAW Close: btgatt-server
{0x0003} 736.953991
> HCI Event: LE Meta Event (0x3e) plen 19 #73 [hci0] 752.270109
LE Connection Complete (0x01)
Status: Success (0x00)
Handle: 64
Role: Slave (0x01)
Peer address type: Public (0x00)
Peer address: 9C:B6:D0:DE:5C:A2 (OUI 9C-B6-D0)
Connection interval: 45.00 msec (0x0024)
Connection latency: 0 (0x0000)
Supervision timeout: 420 msec (0x002a)
Master clock accuracy: 0x00
@ MGMT Event: Device Connected (0x000b) plen 13
{0x0001} [hci0] 752.270401
LE Address: 9C:B6:D0:DE:5C:A2 (OUI 9C-B6-D0)
Flags: 0x00000000
Data length: 0
@ MGMT Event: Device Connected (0x000b) plen 13
{0x0002} [hci0] 752.270401
LE Address: 9C:B6:D0:DE:5C:A2 (OUI 9C-B6-D0)
Flags: 0x00000000
Data length: 0
< HCI Command: LE Read Remote Used Features (0x08|0x0016) plen 2
#74 [hci0] 752.276167
Handle: 64
> HCI Event: Command Status (0x0f) plen 4 #75 [hci0] 752.281522
LE Read Remote Used Features (0x08|0x0016) ncmd 1
Status: Success (0x00)
> HCI Event: LE Meta Event (0x3e) plen 12 #76 [hci0] 752.522510
LE Read Remote Used Features (0x04)
Status: Success (0x00)
Handle: 64
Features: 0x1f 0x00 0x00 0x00 0x00 0x00 0x00 0x00
LE Encryption
Connection Parameter Request Procedure
Extended Reject Indication
Slave-initiated Features Exchange
LE Ping
< ACL Data TX: Handle 64 flags 0x00 dlen 16
#77 [hci0] 752.522823
LE L2CAP: Connection Parameter Update Request (0x12) ident 1 len 8
Min interval: 40
Max interval: 56
Slave latency: 0
Timeout multiplier: 42
> HCI Event: LE Meta Event (0x3e) plen 11 #78 [hci0] 752.612551
LE Remote Connection Parameter Request (0x06)
Handle: 64
Min connection interval: 50.00 msec (0x0028)
Max connection interval: 70.00 msec (0x0038)
Connection latency: 0 (0x0000)
Supervision timeout: 420 msec (0x002a)
< HCI Command: LE Remote Connection Parameter Request Reply
(0x08|0x0020) plen 14 #79 [hci0] 752.612732
Handle: 64
Min connection interval: 50.00 msec (0x0028)
Max connection interval: 70.00 msec (0x0038)
Connection latency: 0 (0x0000)
Supervision timeout: 420 msec (0x002a)
Min connection length: 0.000 msec (0x0000)
Max connection length: 0.000 msec (0x0000)
> HCI Event: Command Complete (0x0e) plen 6 #80 [hci0] 752.622017
LE Remote Connection Parameter Request Reply (0x08|0x0020) ncmd 1
Status: Success (0x00)
Handle: 64
> ACL Data RX: Handle 64 flags 0x02 dlen 10 #81 [hci0] 752.657199
LE L2CAP: Connection Parameter Update Response (0x13) ident 1 len 2
Result: Connection Parameters accepted (0x0000)
> HCI Event: Number of Completed Packets (0x13) plen 5 #82 [hci0] 752.755860
Num handles: 1
Handle: 64
Count: 1
> HCI Event: LE Meta Event (0x3e) plen 10 #83 [hci0] 753.017532
LE Connection Update Complete (0x03)
Status: Success (0x00)
Handle: 64
Connection interval: 60.00 msec (0x0030)
Connection latency: 0 (0x0000)
Supervision timeout: 420 msec (0x002a)
Attempting to connect to another GATT Server (4F:E8:66:0A:92:63)
====================================================
< HCI Command: LE Set Scan Parameters (0x08|0x000b) plen 7
#403 [hci0] 1988.511852
Type: Passive (0x00)
Interval: 60.000 msec (0x0060)
Window: 30.000 msec (0x0030)
Own address type: Public (0x00)
Filter policy: Ignore not in white list (0x01)
> HCI Event: Ccheck_pending_le_conn: le_num_slave = 1
ommand Complete (0x0e) plen 4
#404 [hci0] 1988.517687
LE Set Scan Parameters (0x08|0x000b) ncmd 1
Shci_cs_le_create_conn: conn=972bb800
tatus: Success (0x00)
< HCI Command: LE Set Scan Enable (0x08|0x000c) plen 2
#405 [hci0] 1988.518123
Scanning: Enabled (0x01)
Filter duplicates: Enabled (0x01)
> HCI Event: Command Complete (0x0e) plen 4 #406 [hci0] 1988.523477
LE Set Scan Enable (0x08|0x000c) ncmd 1
Status: Success (0x00)
> HCI Event: LE Meta Event (0x3e) plen 29 #407 [hci0] 1988.551326
LE Advertising Report (0x02)
Num reports: 1
Event type: Connectable undirected - ADV_IND (0x00)
Address type: Random (0x01)
Address: 4F:E8:66:0A:92:63 (Resolvable)
Data length: 17
Flags: 0x02
LE General Discoverable Mode
Name (complete): LG K8 (2017)
RSSI: -71 dBm (0xb9)
< HCI Command: LE Set Scan Enable (0x08|0x000c) plen 2
#408 [hci0] 1988.557402
Scanning: Disabled (0x00)
Filter duplicates: Disabled (0x00)
> HCI Event: Command Complete (0x0e) plen 4 #409 [hci0] 1988.563409
LE Set Scan Enable (0x08|0x000c) ncmd 1
Status: Success (0x00)
< HCI Command: LE Create Connection (0x08|0x000d) plen 25
#410 [hci0] 1988.563891
Scan interval: 60.000 msec (0x0060)
Scan window: 60.000 msec (0x0060)
Filter policy: White list is not used (0x00)
Peer address type: Random (0x01)
Peer address: 4F:E8:66:0A:92:63 (Resolvable)
Own address type: Public (0x00)
Min connection interval: 50.00 msec (0x0028)
Max connection interval: 70.00 msec (0x0038)
Connection latency: 0 (0x0000)
Supervision timeout: 420 msec (0x002a)
Min connection length: 0.000 msec (0x0000)
Max connection length: 0.000 msec (0x0000)
> HCI Event: Command Status (0x0f) plen 4 #411 [hci0] 1988.573442
LE Create Connection (0x08|0x000d) ncmd 1
Status: Success (0x00)
> HCI Event: LE Meta Event (0x3e) plen 19 #412 [hci0] 1988.839656
LE Connection Complete (0x01)
Status: Success (0x00)
Handle: 65
Role: Master (0x00)
Peer address type: Random (0x01)
Peer address: 4F:E8:66:0A:92:63 (Resolvable)
Connection interval: 60.00 msec (0x0030)
Connection latency: 0 (0x0000)
Supervision timeout: 420 msec (0x002a)
Master clock accuracy: 0x00
@ MGMT Event: Device Connected (0x000b) plen 30
{0x0001} [hci0] 1988.839788
LE Address: 4F:E8:66:0A:92:63 (Resolvable)
Flags: 0x00000000
Data length: 17
Flags: 0x02
LE General Discoverable Mode
Name (complete): LG K8 (2017)
@ MGMT Event: Device Connected (0x000b) plen 30
{0x0002} [hci0] 1988.839788
LE Address: 4F:E8:66:0A:92:63 (Resolvable)
Flags: 0x00000000
Data length: 17
Flags: 0x02
LE General Discoverable Mode
Name (complete): LG K8 (2017)
< HCI Command: LE Read Remote Used Features (0x08|0x0016) plen 2
#413 [hci0] 1988.840257
Handle: 65
> HCI Event: Command Status (0x0f) plen 4 #414 [hci0] 1988.846789
LE Read Remote Used Features (0x08|0x0016) ncmd 1
Status: Success (0x00)
> HCI Event: LE Meta Event (0x3e) plen 12 #415 [hci0] 1989.040282
LE Read Remote Used Features (0x04)
Status: Success (0x00)
Handle: 65
Features: 0x0f 0x00 0x00 0x00 0x00 0x00 0x00 0x00
LE Encryption
Connection Parameter Request Procedure
Extended Reject Indication
Slave-initiated Features Exchange
> HCI Event: LE Meta Event (0x3e) plen 11 #416 [hci0] 1989.401375
LE Remote Connection Parameter Request (0x06)
Handle: 65
Min connection interval: 7.50 msec (0x0006)
Max connection interval: 7.50 msec (0x0006)
Connection latency: 0 (0x0000)
Supervision timeout: 5000 msec (0x01f4)
< HCI Command: LE Remote Connection Parameter Request Reply
(0x08|0x0020) plen 14 #417 [hci0] 1989.401742
Handle: 65
Min connection interval: 7.50 msec (0x0006)
Max connection interval: 7.50 msec (0x0006)
Connection latency: 0 (0x0000)
Supervision timeout: 5000 msec (0x01f4)
Min connection length: 0.000 msec (0x0000)
Max connection length: 0.000 msec (0x0000)
> HCI Event: Command Complete (0x0e) plen 6 #418 [hci0] 1989.410534
LE Remote Connection Parameter Request Reply (0x08|0x0020) ncmd 1
Status: Success (0x00)
Handle: 65
> ACL Data RX: Handle 65 flags 0x02 dlen 11 #419 [hci0] 1989.460209
ATT: Read By Group Type Request (0x10) len 6
Handle range: 0x0001-0xffff
Attribute group type: Primary Service (0x2800)
< ACL Data TX: Handle 65 flags 0x00 dlen 9
#420 [hci0] 1989.461006
ATT: Error Response (0x01) len 4
Read By Group Type Request (0x10)
Handle: 0x0000
Error: Request Not Supported (0x06)
> HCI Event: Number of Completed Packets (0x13) plen 5 #421 [hci0] 1989.657151
Num handles: 1
Handle: 65
Count: 1
> HCI Event: LE Meta Event (0x3e) plen 10 #422 [hci0] 1989.886359
LE Connection Update Complete (0x03)
Status: Success (0x00)
Handle: 65
Connection interval: 7.50 msec (0x0006)
Connection latency: 0 (0x0000)
Supervision timeout: 5000 msec (0x01f4)
> HCI Event: LE Meta Event (0x3e) plen 11 #423 [hci0] 1989.894763
LE Remote Connection Parameter Request (0x06)
Handle: 65
Min connection interval: 60.00 msec (0x0030)
Max connection interval: 60.00 msec (0x0030)
Connection latency: 0 (0x0000)
Supervision timeout: 420 msec (0x002a)
< HCI Command: LE Remote Connection Parameter Request Reply
(0x08|0x0020) plen 14 #424 [hci0] 1989.895117
Handle: 65
Min connection interval: 60.00 msec (0x0030)
Max connection interval: 60.00 msec (0x0030)
Connection latency: 0 (0x0000)
Supervision timeout: 420 msec (0x002a)
Min connection length: 0.000 msec (0x0000)
Max connection length: 0.000 msec (0x0000)
> HCI Event: Command Complete (0x0e) plen 6 #425 [hci0] 1989.903898
LE Remote Connection Parameter Request Reply (0x08|0x0020) ncmd 1
Status: Success (0x00)
Handle: 65
> HCI Event: LE Meta Event (0x3e) plen 10 #426 [hci0] 1989.988169
LE Connection Update Complete (0x03)
Status: Success (0x00)
Handle: 65
Connection interval: 60.00 msec (0x0030)
Connection latency: 0 (0x0000)
Supervision timeout: 420 msec (0x002a)
which now seems to be working, I think maybe the first time I tried
connecting I didn't specify that the address was a random address for
the connection to the GATT Server running on my phone using nRF.
I do have this patch in place to remove the check on le_num_slave as
per the suggestion by Luiz
@@ -4651,6 +4652,7 @@ static struct hci_conn
*check_pending_le_conn(struct hci_dev *hdev,
struct hci_conn *conn;
struct hci_conn_params *params;
+printk(KERN_ERR "%s: le_num_slave = %d\n", __func__,
hdev->conn_hash.le_num_slave);
/* If the event is not connectable don't proceed further */
if (adv_type != LE_ADV_IND && adv_type != LE_ADV_DIRECT_IND)
return NULL;
@@ -4662,8 +4664,10 @@ static struct hci_conn
*check_pending_le_conn(struct hci_dev *hdev,
/* Most controller will fail if we try to create new connections
* while we have an existing one in slave role.
*/
+#if 0
if (hdev->conn_hash.le_num_slave > 0)
return NULL;
+#endif
/* If we're not connectable only connect devices that we have in
* our pend_le_conns list.
And during the connection I do now see the following in the journal
ov 09 08:57:59 mach-cw-rnet-ppm-1717 kernel: check_pending_le_conn:
le_num_slave = 1
Nov 09 08:57:59 mach-cw-rnet-ppm-1717 kernel: hci0 opcode 0x200c plen 2
Nov 09 08:57:59 mach-cw-rnet-ppm-1717 kernel: skb len 5
which does suggest you were right Luiz. I'll take the patch out and
retry the experiment to make sure.
Cheers,
Martin
On Thu, Nov 15, 2018 at 4:54 PM Martin Townsend <[email protected]> wrote:
>
> On Tue, Nov 13, 2018 at 11:21 AM Luiz Augusto von Dentz
> <[email protected]> wrote:
> >
> > Hi Emil, Martin,
> > On Tue, Nov 13, 2018 at 12:47 PM Emil Lenngren <[email protected]> wrote:
> > >
> > > Hi,
> > >
> > > Den mån 12 nov. 2018 kl 17:19 skrev Martin Townsend <[email protected]>:
> > > > I've just been reading the 4.1 spec on GAP and on page 224 it states:
> > > >
> > > >
> > > > "In LE, GAP defines four specific roles: Broadcaster, Observer, Peripheral, and
> > > > Central. A device may support multiple LE GAP roles provided that the underly-
> > > > ing Controller supports those roles or role combinations. However, only one LE
> > > > GAP role may be supported at a given time. Each role specifies the require-
> > > > ments for the underlying Controller. This allows for Controllers to be optimized
> > > > for specific use cases."
> > > >
> > > > Now to me that says a device can support being a central and
> > > > peripheral but doesn't have to support them concurrently so I'm
> > > > guessing if the device is in the peripheral role and then wanted to
> > > > connect to another device you would have to stop being a peripheral
> > > > (ie drop this connection) and then become a central, make the
> > > > connection and when finished disconnect and become a peripheral again
> > > > and wait for the other devices to reconnect to you. Or am I
> > > > mis-reading this?
> > >
> > > This restriction is lifted in newer versions of the spec. The same
> > > section in version 4.2 says this:
> > > "In LE, GAP defines four specific roles: Broadcaster, Observer, Peripheral, and
> > > Central. A device may support multiple LE GAP roles provided that the
> > > underlying Controller supports those roles or role combinations. Each role
> > > specifies the requirements for the underlying Controller. This allows for
> > > Controllers to be optimized for specific use cases."
> > >
> > > If you use the btmon tool you can easily see what combination of
> > > supported states the controller supports. If you have btmon running
> > > while you initiate bluetoothd you will see the packet LE Read
> > > Supported States Command, which contains this info.
> >
> > In that case we should definitely use these states to determine
> > instead of assuming the controller don't support Master & Slave state,
> > though it would be great if Martin provides the HCI traces where it is
> > failing and if indeed is the controller not support it or some other
> > bug.
> >
> > --
> > Luiz Augusto von Dentz
>
> Apologies for the delay. I've heard back from the device manufacture
> and they have confirmed that it does support both roles simultaneously
> and have proved this using their WICED platform.
> https://community.cypress.com/thread/36729
>
> So I have ran btmon and then powered the device and get the following
> LE Read Supported States message in the log (let me know if you want
> the full log or other messages, there were quite a few of them)
>
> < HCI Command: LE Read Supported States (0x08|0x001c) plen 0
> #27 [hci0] 12.173109
> > HCI Event: Command Complete (0x0e) plen 12 #28 [hci0] 12.178836
> LE Read Supported States (0x08|0x001c) ncmd 1
> Status: Success (0x00)
> States: 0x000003ffffffffff
> Non-connectable Advertising State
> Scannable Advertising State
> Connectable Advertising State
> High Duty Cycle Directed Advertising State
> Passive Scanning State
> Active Scanning State
> Initiating State
> and Connection State (Master Role)
> Connection State (Slave Role)
> Non-connectable Advertising State
> and Passive Scanning State
> Scannable Advertising State
> and Passive Scanning State
> Connectable Advertising State
> and Passive Scanning State
> High Duty Cycle Directed Advertising State
> and Passive Scanning State
> Non-connectable Advertising State
> and Active Scanning State
> Scannable Advertising State
> and Active Scanning State
> Connectable Advertising State
> and Active Scanning State
> High Duty Cycle Directed Advertising State
> and Active Scanning State
> Non-connectable Advertising State
> and Initiating State
> Scannable Advertising State
> and Initiating State
> Non-connectable Advertising State
> and Connection State (Master Role)
> Scannable Advertising State
> and Connection State (Master Role)
> Non-connectable Advertising State
> and Connection State (Slave Role)
> Scannable Advertising State
> and Connection State (Slave Role)
> Passive Scanning State
> and Initiating State
> Active Scanning State
> and Initiating State
> Passive Scanning State
> and Connection State (Master Role)
> Active Scanning State
> and Connection State (Master Role)
> Passive Scanning State
> and Connection State (Slave Role)
> Active Scanning State
> and Connection State (Slave Role)
> Initiating State
> and Connection State (Master Role)
> and Master Role & Master Role
> Low Duty Cycle Directed Advertising State
> Low Duty Cycle Directed Advertising State
> and Passive Scanning State
> Low Duty Cycle Directed Advertising State
> and Active Scanning State
> Connectable Advertising State
> and Initiating State
> and Master Role & Slave Role
> High Duty Cycle Directed Advertising State
> and Initiating State
> and Master Role & Slave Role
> Low Duty Cycle Directed Advertising State
> and Initiating State
> and Master Role & Slave Role
> Connectable Advertising State
> and Connection State (Master Role)
> and Master Role & Slave Role
> High Duty Cycle Directed Advertising State
> and Connection State (Master Role)
> and Master Role & Slave Role
> Low Duty Cycle Directed Advertising State
> and Connection State (Master Role)
> and Master Role & Slave Role
> Connectable Advertising State
> and Connection State (Slave Role)
> and Master Role & Slave Role
> High Duty Cycle Directed Advertising State
> and Connection State (Slave Role)
> and Slave Role & Slave Role
> Low Duty Cycle Directed Advertising State
> and Connection State (Slave Role)
> and Slave Role & Slave Role
> Initiating State
> and Connection State (Slave Role)
> and Master Role & Slave Role
>
> Using btmon I then captured the HCI trace for the failing dual role case
>
> Starting the GATT Server and connecting from a PC
> ========================================
> < HCI Command: LE Set Advertising Parameters (0x08|0x0006) plen 15
> #69 [hci0] 736.868434
> Min advertising interval: 1280.000 msec (0x0800)
> Max advertising interval: 1280.000 msec (0x0800)
> Type: Connectable undirected - ADV_IND (0x00)
> Own address type: Public (0x00)
> Direct address type: Public (0x00)
> Direct address: 00:00:00:00:00:00 (OUI 00-00-00)
> Channel map: 37, 38, 39 (0x07)
> Filter policy: Allow Scan Request from Any, Allow Connect
> Request from Any (0x00)
> > HCI Event: Command Complete (0x0e) plen 4 #70 [hci0] 736.875133
> LE Set Advertising Parameters (0x08|0x0006) ncmd 1
> Status: Success (0x00)
> < HCI Command: LE Set Advertise Enable (0x08|0x000a) plen 1
> #71 [hci0] 736.878291
> Advertising: Enabled (0x01)
> > HCI Event: Command Complete (0x0e) plen 4 #72 [hci0] 736.883585
> LE Set Advertise Enable (0x08|0x000a) ncmd 1
> Status: Success (0x00)
> @ RAW Close: hciconfig
> {0x0004} [hci0] 736.884982
> @ RAW Close: hciconfig
> {0x0003} 736.885139
> @ RAW Open: btgatt-server (privileged) version 2.22
> {0x0003} 736.950116
> @ RAW Close: btgatt-server
> {0x0003} 736.953288
> @ RAW Open: btgatt-server (privileged) version 2.22
> {0x0003} 736.953693
> @ RAW Close: btgatt-server
> {0x0003} 736.953991
> > HCI Event: LE Meta Event (0x3e) plen 19 #73 [hci0] 752.270109
> LE Connection Complete (0x01)
> Status: Success (0x00)
> Handle: 64
> Role: Slave (0x01)
> Peer address type: Public (0x00)
> Peer address: 9C:B6:D0:DE:5C:A2 (OUI 9C-B6-D0)
> Connection interval: 45.00 msec (0x0024)
> Connection latency: 0 (0x0000)
> Supervision timeout: 420 msec (0x002a)
> Master clock accuracy: 0x00
> @ MGMT Event: Device Connected (0x000b) plen 13
> {0x0001} [hci0] 752.270401
> LE Address: 9C:B6:D0:DE:5C:A2 (OUI 9C-B6-D0)
> Flags: 0x00000000
> Data length: 0
> @ MGMT Event: Device Connected (0x000b) plen 13
> {0x0002} [hci0] 752.270401
> LE Address: 9C:B6:D0:DE:5C:A2 (OUI 9C-B6-D0)
> Flags: 0x00000000
> Data length: 0
> < HCI Command: LE Read Remote Used Features (0x08|0x0016) plen 2
> #74 [hci0] 752.276167
> Handle: 64
> > HCI Event: Command Status (0x0f) plen 4 #75 [hci0] 752.281522
> LE Read Remote Used Features (0x08|0x0016) ncmd 1
> Status: Success (0x00)
> > HCI Event: LE Meta Event (0x3e) plen 12 #76 [hci0] 752.522510
> LE Read Remote Used Features (0x04)
> Status: Success (0x00)
> Handle: 64
> Features: 0x1f 0x00 0x00 0x00 0x00 0x00 0x00 0x00
> LE Encryption
> Connection Parameter Request Procedure
> Extended Reject Indication
> Slave-initiated Features Exchange
> LE Ping
> < ACL Data TX: Handle 64 flags 0x00 dlen 16
> #77 [hci0] 752.522823
> LE L2CAP: Connection Parameter Update Request (0x12) ident 1 len 8
> Min interval: 40
> Max interval: 56
> Slave latency: 0
> Timeout multiplier: 42
> > HCI Event: LE Meta Event (0x3e) plen 11 #78 [hci0] 752.612551
> LE Remote Connection Parameter Request (0x06)
> Handle: 64
> Min connection interval: 50.00 msec (0x0028)
> Max connection interval: 70.00 msec (0x0038)
> Connection latency: 0 (0x0000)
> Supervision timeout: 420 msec (0x002a)
> < HCI Command: LE Remote Connection Parameter Request Reply
> (0x08|0x0020) plen 14 #79 [hci0] 752.612732
> Handle: 64
> Min connection interval: 50.00 msec (0x0028)
> Max connection interval: 70.00 msec (0x0038)
> Connection latency: 0 (0x0000)
> Supervision timeout: 420 msec (0x002a)
> Min connection length: 0.000 msec (0x0000)
> Max connection length: 0.000 msec (0x0000)
> > HCI Event: Command Complete (0x0e) plen 6 #80 [hci0] 752.622017
> LE Remote Connection Parameter Request Reply (0x08|0x0020) ncmd 1
> Status: Success (0x00)
> Handle: 64
> > ACL Data RX: Handle 64 flags 0x02 dlen 10 #81 [hci0] 752.657199
> LE L2CAP: Connection Parameter Update Response (0x13) ident 1 len 2
> Result: Connection Parameters accepted (0x0000)
> > HCI Event: Number of Completed Packets (0x13) plen 5 #82 [hci0] 752.755860
> Num handles: 1
> Handle: 64
> Count: 1
> > HCI Event: LE Meta Event (0x3e) plen 10 #83 [hci0] 753.017532
> LE Connection Update Complete (0x03)
> Status: Success (0x00)
> Handle: 64
> Connection interval: 60.00 msec (0x0030)
> Connection latency: 0 (0x0000)
> Supervision timeout: 420 msec (0x002a)
>
>
>
> Attempting to connect to another GATT Server (4F:E8:66:0A:92:63)
> ====================================================
> < HCI Command: LE Set Scan Parameters (0x08|0x000b) plen 7
> #403 [hci0] 1988.511852
> Type: Passive (0x00)
> Interval: 60.000 msec (0x0060)
> Window: 30.000 msec (0x0030)
> Own address type: Public (0x00)
> Filter policy: Ignore not in white list (0x01)
> > HCI Event: Ccheck_pending_le_conn: le_num_slave = 1
> ommand Complete (0x0e) plen 4
> #404 [hci0] 1988.517687
> LE Set Scan Parameters (0x08|0x000b) ncmd 1
> Shci_cs_le_create_conn: conn=972bb800
> tatus: Success (0x00)
> < HCI Command: LE Set Scan Enable (0x08|0x000c) plen 2
> #405 [hci0] 1988.518123
> Scanning: Enabled (0x01)
> Filter duplicates: Enabled (0x01)
> > HCI Event: Command Complete (0x0e) plen 4 #406 [hci0] 1988.523477
> LE Set Scan Enable (0x08|0x000c) ncmd 1
> Status: Success (0x00)
> > HCI Event: LE Meta Event (0x3e) plen 29 #407 [hci0] 1988.551326
> LE Advertising Report (0x02)
> Num reports: 1
> Event type: Connectable undirected - ADV_IND (0x00)
> Address type: Random (0x01)
> Address: 4F:E8:66:0A:92:63 (Resolvable)
> Data length: 17
> Flags: 0x02
> LE General Discoverable Mode
> Name (complete): LG K8 (2017)
> RSSI: -71 dBm (0xb9)
> < HCI Command: LE Set Scan Enable (0x08|0x000c) plen 2
> #408 [hci0] 1988.557402
> Scanning: Disabled (0x00)
> Filter duplicates: Disabled (0x00)
> > HCI Event: Command Complete (0x0e) plen 4 #409 [hci0] 1988.563409
> LE Set Scan Enable (0x08|0x000c) ncmd 1
> Status: Success (0x00)
> < HCI Command: LE Create Connection (0x08|0x000d) plen 25
> #410 [hci0] 1988.563891
> Scan interval: 60.000 msec (0x0060)
> Scan window: 60.000 msec (0x0060)
> Filter policy: White list is not used (0x00)
> Peer address type: Random (0x01)
> Peer address: 4F:E8:66:0A:92:63 (Resolvable)
> Own address type: Public (0x00)
> Min connection interval: 50.00 msec (0x0028)
> Max connection interval: 70.00 msec (0x0038)
> Connection latency: 0 (0x0000)
> Supervision timeout: 420 msec (0x002a)
> Min connection length: 0.000 msec (0x0000)
> Max connection length: 0.000 msec (0x0000)
> > HCI Event: Command Status (0x0f) plen 4 #411 [hci0] 1988.573442
> LE Create Connection (0x08|0x000d) ncmd 1
> Status: Success (0x00)
> > HCI Event: LE Meta Event (0x3e) plen 19 #412 [hci0] 1988.839656
> LE Connection Complete (0x01)
> Status: Success (0x00)
> Handle: 65
> Role: Master (0x00)
> Peer address type: Random (0x01)
> Peer address: 4F:E8:66:0A:92:63 (Resolvable)
> Connection interval: 60.00 msec (0x0030)
> Connection latency: 0 (0x0000)
> Supervision timeout: 420 msec (0x002a)
> Master clock accuracy: 0x00
> @ MGMT Event: Device Connected (0x000b) plen 30
> {0x0001} [hci0] 1988.839788
> LE Address: 4F:E8:66:0A:92:63 (Resolvable)
> Flags: 0x00000000
> Data length: 17
> Flags: 0x02
> LE General Discoverable Mode
> Name (complete): LG K8 (2017)
> @ MGMT Event: Device Connected (0x000b) plen 30
> {0x0002} [hci0] 1988.839788
> LE Address: 4F:E8:66:0A:92:63 (Resolvable)
> Flags: 0x00000000
> Data length: 17
> Flags: 0x02
> LE General Discoverable Mode
> Name (complete): LG K8 (2017)
> < HCI Command: LE Read Remote Used Features (0x08|0x0016) plen 2
> #413 [hci0] 1988.840257
> Handle: 65
> > HCI Event: Command Status (0x0f) plen 4 #414 [hci0] 1988.846789
> LE Read Remote Used Features (0x08|0x0016) ncmd 1
> Status: Success (0x00)
> > HCI Event: LE Meta Event (0x3e) plen 12 #415 [hci0] 1989.040282
> LE Read Remote Used Features (0x04)
> Status: Success (0x00)
> Handle: 65
> Features: 0x0f 0x00 0x00 0x00 0x00 0x00 0x00 0x00
> LE Encryption
> Connection Parameter Request Procedure
> Extended Reject Indication
> Slave-initiated Features Exchange
> > HCI Event: LE Meta Event (0x3e) plen 11 #416 [hci0] 1989.401375
> LE Remote Connection Parameter Request (0x06)
> Handle: 65
> Min connection interval: 7.50 msec (0x0006)
> Max connection interval: 7.50 msec (0x0006)
> Connection latency: 0 (0x0000)
> Supervision timeout: 5000 msec (0x01f4)
> < HCI Command: LE Remote Connection Parameter Request Reply
> (0x08|0x0020) plen 14 #417 [hci0] 1989.401742
> Handle: 65
> Min connection interval: 7.50 msec (0x0006)
> Max connection interval: 7.50 msec (0x0006)
> Connection latency: 0 (0x0000)
> Supervision timeout: 5000 msec (0x01f4)
> Min connection length: 0.000 msec (0x0000)
> Max connection length: 0.000 msec (0x0000)
> > HCI Event: Command Complete (0x0e) plen 6 #418 [hci0] 1989.410534
> LE Remote Connection Parameter Request Reply (0x08|0x0020) ncmd 1
> Status: Success (0x00)
> Handle: 65
> > ACL Data RX: Handle 65 flags 0x02 dlen 11 #419 [hci0] 1989.460209
> ATT: Read By Group Type Request (0x10) len 6
> Handle range: 0x0001-0xffff
> Attribute group type: Primary Service (0x2800)
> < ACL Data TX: Handle 65 flags 0x00 dlen 9
> #420 [hci0] 1989.461006
> ATT: Error Response (0x01) len 4
> Read By Group Type Request (0x10)
> Handle: 0x0000
> Error: Request Not Supported (0x06)
> > HCI Event: Number of Completed Packets (0x13) plen 5 #421 [hci0] 1989.657151
> Num handles: 1
> Handle: 65
> Count: 1
> > HCI Event: LE Meta Event (0x3e) plen 10 #422 [hci0] 1989.886359
> LE Connection Update Complete (0x03)
> Status: Success (0x00)
> Handle: 65
> Connection interval: 7.50 msec (0x0006)
> Connection latency: 0 (0x0000)
> Supervision timeout: 5000 msec (0x01f4)
> > HCI Event: LE Meta Event (0x3e) plen 11 #423 [hci0] 1989.894763
> LE Remote Connection Parameter Request (0x06)
> Handle: 65
> Min connection interval: 60.00 msec (0x0030)
> Max connection interval: 60.00 msec (0x0030)
> Connection latency: 0 (0x0000)
> Supervision timeout: 420 msec (0x002a)
> < HCI Command: LE Remote Connection Parameter Request Reply
> (0x08|0x0020) plen 14 #424 [hci0] 1989.895117
> Handle: 65
> Min connection interval: 60.00 msec (0x0030)
> Max connection interval: 60.00 msec (0x0030)
> Connection latency: 0 (0x0000)
> Supervision timeout: 420 msec (0x002a)
> Min connection length: 0.000 msec (0x0000)
> Max connection length: 0.000 msec (0x0000)
> > HCI Event: Command Complete (0x0e) plen 6 #425 [hci0] 1989.903898
> LE Remote Connection Parameter Request Reply (0x08|0x0020) ncmd 1
> Status: Success (0x00)
> Handle: 65
> > HCI Event: LE Meta Event (0x3e) plen 10 #426 [hci0] 1989.988169
> LE Connection Update Complete (0x03)
> Status: Success (0x00)
> Handle: 65
> Connection interval: 60.00 msec (0x0030)
> Connection latency: 0 (0x0000)
> Supervision timeout: 420 msec (0x002a)
>
>
> which now seems to be working, I think maybe the first time I tried
> connecting I didn't specify that the address was a random address for
> the connection to the GATT Server running on my phone using nRF.
>
> I do have this patch in place to remove the check on le_num_slave as
> per the suggestion by Luiz
> @@ -4651,6 +4652,7 @@ static struct hci_conn
> *check_pending_le_conn(struct hci_dev *hdev,
> struct hci_conn *conn;
> struct hci_conn_params *params;
>
> +printk(KERN_ERR "%s: le_num_slave = %d\n", __func__,
> hdev->conn_hash.le_num_slave);
> /* If the event is not connectable don't proceed further */
> if (adv_type != LE_ADV_IND && adv_type != LE_ADV_DIRECT_IND)
> return NULL;
> @@ -4662,8 +4664,10 @@ static struct hci_conn
> *check_pending_le_conn(struct hci_dev *hdev,
> /* Most controller will fail if we try to create new connections
> * while we have an existing one in slave role.
> */
> +#if 0
> if (hdev->conn_hash.le_num_slave > 0)
> return NULL;
> +#endif
>
> /* If we're not connectable only connect devices that we have in
> * our pend_le_conns list.
>
> And during the connection I do now see the following in the journal
>
> ov 09 08:57:59 mach-cw-rnet-ppm-1717 kernel: check_pending_le_conn:
> le_num_slave = 1
> Nov 09 08:57:59 mach-cw-rnet-ppm-1717 kernel: hci0 opcode 0x200c plen 2
> Nov 09 08:57:59 mach-cw-rnet-ppm-1717 kernel: skb len 5
>
> which does suggest you were right Luiz. I'll take the patch out and
> retry the experiment to make sure.
>
> Cheers,
> Martin
I took that patch out and added a printk(KERN_ERR "FAILED CONNECTION
le_num_slave > 0); before returning NULL and it does fail the
connection and I do see the message in the journal:
Nov 09 07:56:23 mach-cw-rnet-ppm-1717 kernel: check_pending_le_conn:
le_num_slave = 1
Nov 09 07:56:23 mach-cw-rnet-ppm-1717 kernel: FAILED CONNECTION le_num_slave > 0