Hi, On Sat, Nov 10, 2018 at 6:03 PM Luiz Augusto von Dentz <luiz.dentz@xxxxxxxxx> wrote: > > Hi Martin, > On Fri, Nov 9, 2018 at 7:57 PM Martin Townsend <mtownsend1973@xxxxxxxxx> wrote: > > > > On Fri, Nov 9, 2018 at 4:32 PM Martin Townsend <mtownsend1973@xxxxxxxxx> 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.
