linux-bluetooth.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* Operating central and peripheral roles concurrently
@ 2019-03-05 10:54 Martin Townsend
  0 siblings, 0 replies; 11+ messages in thread
From: Martin Townsend @ 2019-03-05 10:54 UTC (permalink / raw)
  To: Luiz Augusto von Dentz, linux-bluetooth, Emil Lenngren

Hi,

I sent an email November last year about Operating central and
peripheral roles concurrently
https://www.spinics.net/lists/linux-bluetooth/msg77673.html

And although we had the dual roles working thanks to the suggested
patch the dev team has reported that if the device (central) connects
to the board (peripheral) first, and then having the board (central)
connecting to a sensor (peripheral), dual roles work fine.

But the other way around, board (central) connects to a sensor (peripheral),
advertisements stop being sent and no other device can no longer connect to
the board (peripheral).

Here's the hcidump trace after running 'hciconfig hci0 leadv 1':

HCI Command: LE Set Advertise Enable (0x08|0x000a) plen 1
   0000: 01
HCI Event: Command Complete (0x0e) plen 4
   LE Set Advertise Enable (0x08|0x000a) ncmd 1
   status 0x00

Then within a second we get the following in hcidump which shows it
being disabled

HCI Command: LE Set Advertise Enable (0x08|0x000a) plen 1
   0000: 00
HCI Event: Command Complete (0x0e) plen 4
   LE Set Advertise Enable (0x08|0x000a) ncmd 1
   status 0x00

I would really appreciate it if someone could point me to the relevant
place in the Kernel code where this could be occurring so I can start
to debug this or even suggest a patch I could try.  The kernel version
is v4.9.

Many Thanks,

Martin.

^ permalink raw reply	[flat|nested] 11+ messages in thread
* Re: Operating central and peripheral roles concurrently
  2018-11-15 16:54               ` Martin Townsend
@ 2018-11-15 17:10                 ` Martin Townsend
  0 siblings, 0 replies; 11+ messages in thread
From: Martin Townsend @ 2018-11-15 17:10 UTC (permalink / raw)
  To: Luiz Augusto von Dentz; +Cc: emil.lenngren, linux-bluetooth

On Thu, Nov 15, 2018 at 4:54 PM Martin Townsend <mtownsend1973@gmail.com> wrote:
>
> On Tue, Nov 13, 2018 at 11:21 AM Luiz Augusto von Dentz
> <luiz.dentz@gmail.com> wrote:
> >
> > Hi Emil, Martin,
> > On Tue, Nov 13, 2018 at 12:47 PM Emil Lenngren <emil.lenngren@gmail.com> wrote:
> > >
> > > Hi,
> > >
> > > Den mån 12 nov. 2018 kl 17:19 skrev Martin Townsend <mtownsend1973@gmail.com>:
> > > > 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

^ permalink raw reply	[flat|nested] 11+ messages in thread
* Re: Operating central and peripheral roles concurrently
  2018-11-13 11:21             ` Luiz Augusto von Dentz
@ 2018-11-15 16:54               ` Martin Townsend
  2018-11-15 17:10                 ` Martin Townsend
  0 siblings, 1 reply; 11+ messages in thread
From: Martin Townsend @ 2018-11-15 16:54 UTC (permalink / raw)
  To: Luiz Augusto von Dentz; +Cc: emil.lenngren, linux-bluetooth

On Tue, Nov 13, 2018 at 11:21 AM Luiz Augusto von Dentz
<luiz.dentz@gmail.com> wrote:
>
> Hi Emil, Martin,
> On Tue, Nov 13, 2018 at 12:47 PM Emil Lenngren <emil.lenngren@gmail.com> wrote:
> >
> > Hi,
> >
> > Den mån 12 nov. 2018 kl 17:19 skrev Martin Townsend <mtownsend1973@gmail.com>:
> > > 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

^ permalink raw reply	[flat|nested] 11+ messages in thread
* Re: Operating central and peripheral roles concurrently
  2018-11-13 10:47           ` Emil Lenngren
@ 2018-11-13 11:21             ` Luiz Augusto von Dentz
  2018-11-15 16:54               ` Martin Townsend
  0 siblings, 1 reply; 11+ messages in thread
From: Luiz Augusto von Dentz @ 2018-11-13 11:21 UTC (permalink / raw)
  To: Emil Lenngren; +Cc: Martin Townsend, linux-bluetooth

Hi Emil, Martin,
On Tue, Nov 13, 2018 at 12:47 PM Emil Lenngren <emil.lenngren@gmail.com> wrote:
>
> Hi,
>
> Den mån 12 nov. 2018 kl 17:19 skrev Martin Townsend <mtownsend1973@gmail.com>:
> > 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

^ permalink raw reply	[flat|nested] 11+ messages in thread
* Re: Operating central and peripheral roles concurrently
  2018-11-12 16:17         ` Martin Townsend
@ 2018-11-13 10:47           ` Emil Lenngren
  2018-11-13 11:21             ` Luiz Augusto von Dentz
  0 siblings, 1 reply; 11+ messages in thread
From: Emil Lenngren @ 2018-11-13 10:47 UTC (permalink / raw)
  To: mtownsend1973; +Cc: Luiz Augusto von Dentz, Bluez mailing list

Hi,

Den mån 12 nov. 2018 kl 17:19 skrev Martin Townsend <mtownsend1973@gmail.com>:
> 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.

^ permalink raw reply	[flat|nested] 11+ messages in thread
* Re: Operating central and peripheral roles concurrently
  2018-11-12 13:52       ` Martin Townsend
@ 2018-11-12 16:17         ` Martin Townsend
  2018-11-13 10:47           ` Emil Lenngren
  0 siblings, 1 reply; 11+ messages in thread
From: Martin Townsend @ 2018-11-12 16:17 UTC (permalink / raw)
  To: Luiz Augusto von Dentz; +Cc: linux-bluetooth

On Mon, Nov 12, 2018 at 1:52 PM Martin Townsend <mtownsend1973@gmail.com> wrote:
>
> Hi,
> On Sat, Nov 10, 2018 at 6:29 PM Martin Townsend <mtownsend1973@gmail.com> wrote:
> >
> > Hi,
> > On Sat, Nov 10, 2018 at 6:03 PM Luiz Augusto von Dentz
> > <luiz.dentz@gmail.com> wrote:
> > >
> > > 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
> >
> > 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?

^ permalink raw reply	[flat|nested] 11+ messages in thread
* Re: Operating central and peripheral roles concurrently
  2018-11-10 18:29     ` Martin Townsend
@ 2018-11-12 13:52       ` Martin Townsend
  2018-11-12 16:17         ` Martin Townsend
  0 siblings, 1 reply; 11+ messages in thread
From: Martin Townsend @ 2018-11-12 13:52 UTC (permalink / raw)
  To: Luiz Augusto von Dentz; +Cc: linux-bluetooth

Hi,
On Sat, Nov 10, 2018 at 6:29 PM Martin Townsend <mtownsend1973@gmail.com> wrote:
>
> Hi,
> On Sat, Nov 10, 2018 at 6:03 PM Luiz Augusto von Dentz
> <luiz.dentz@gmail.com> wrote:
> >
> > 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
>
> 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.

^ permalink raw reply	[flat|nested] 11+ messages in thread
* Re: Operating central and peripheral roles concurrently
  2018-11-10 18:03   ` Luiz Augusto von Dentz
@ 2018-11-10 18:29     ` Martin Townsend
  2018-11-12 13:52       ` Martin Townsend
  0 siblings, 1 reply; 11+ messages in thread
From: Martin Townsend @ 2018-11-10 18:29 UTC (permalink / raw)
  To: luiz.dentz; +Cc: linux-bluetooth

Hi,
On Sat, Nov 10, 2018 at 6:03 PM Luiz Augusto von Dentz
<luiz.dentz@gmail.com> wrote:
>
> 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

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.

^ permalink raw reply	[flat|nested] 11+ messages in thread
* Re: Operating central and peripheral roles concurrently
  2018-11-09 17:55 ` Martin Townsend
@ 2018-11-10 18:03   ` Luiz Augusto von Dentz
  2018-11-10 18:29     ` Martin Townsend
  0 siblings, 1 reply; 11+ messages in thread
From: Luiz Augusto von Dentz @ 2018-11-10 18:03 UTC (permalink / raw)
  To: mtownsend1973; +Cc: linux-bluetooth

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

^ permalink raw reply	[flat|nested] 11+ messages in thread
* Re: Operating central and peripheral roles concurrently
  2018-11-09 16:32 Martin Townsend
@ 2018-11-09 17:55 ` Martin Townsend
  2018-11-10 18:03   ` Luiz Augusto von Dentz
  0 siblings, 1 reply; 11+ messages in thread
From: Martin Townsend @ 2018-11-09 17:55 UTC (permalink / raw)
  To: linux-bluetooth

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

Regards, Martin.

^ permalink raw reply	[flat|nested] 11+ messages in thread
* Operating central and peripheral roles concurrently
@ 2018-11-09 16:32 Martin Townsend
  2018-11-09 17:55 ` Martin Townsend
  0 siblings, 1 reply; 11+ messages in thread
From: Martin Townsend @ 2018-11-09 16:32 UTC (permalink / raw)
  To: linux-bluetooth

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.

^ permalink raw reply	[flat|nested] 11+ messages in thread
end of thread, other threads:[~2019-03-05 10:54 UTC | newest]

Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-03-05 10:54 Operating central and peripheral roles concurrently Martin Townsend
  -- strict thread matches above, loose matches on Subject: below --
2018-11-09 16:32 Martin Townsend
2018-11-09 17:55 ` Martin Townsend
2018-11-10 18:03   ` Luiz Augusto von Dentz
2018-11-10 18:29     ` Martin Townsend
2018-11-12 13:52       ` Martin Townsend
2018-11-12 16:17         ` Martin Townsend
2018-11-13 10:47           ` Emil Lenngren
2018-11-13 11:21             ` Luiz Augusto von Dentz
2018-11-15 16:54               ` Martin Townsend
2018-11-15 17:10                 ` Martin Townsend

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).