Problems with incoming connection request on Nexus 4

Problems with incoming connection request on Nexus 4

[Florian Grandel]

Hi Marcel and Szymon,

I'm currently testing my code on my Nexus 4 device. Multi-Advertising 
works nicely but I can't get the device to accept incoming connection 
requests while in peripheral mode. I'm using Nordic's nRF Master Control 
app on my Samsung S4 in the central role for testing.

Here some sample debug output. When launching the connection request I get:

07-29 03:14:36.816  16843-16843/? I/bluetoothd﹕
mgmt_if: > 0b 00 00 00 1e 00 05 46 ab c2 01 94 00 00 00 00
.......F........

07-29 03:14:36.816  16843-16843/? I/bluetoothd﹕
mgmt_if:   00 11 00 0b 09 66 67 2d 73 61 6d 73 75 6e 67 04
.....fg-samsung.

07-29 03:14:36.816  16843-16843/? I/bluetoothd﹕
mgmt_if:   0d 0c 02 5a
...Z

07-29 03:14:36.816  16843-16843/? I/bluetoothd﹕
mgmt_if: [0x0000] event 0x000b

07-29 03:14:36.816  16843-16843/? D/bluetoothd﹕
external/bluetooth/bluez/android/bluetooth.c:mgmt_device_connected_event() 
94:01:C2:AB:46:05 type 0

07-29 03:14:36.829  16817-16875/com.android.bluetooth D/BlueZ﹕ 
external/bluetooth/bluez/android/hal-bluetooth.c:handle_acl_state_changed() 
state 0

07-29 03:14:37.100  16843-16843/? D/bluetoothd﹕ 
external/bluetooth/bluez/android/gatt.c:connect_confirm()

07-29 03:14:37.100  16843-16843/? D/bluetoothd﹕ 
external/bluetooth/bluez/android/gatt.c:device_set_state() gatt: Device 
94:01:C2:AB:46:05 state changed DISCONNECTED -> CONNECT READY


And then after the timeout:

07-29 03:15:07.083  16843-16843/? D/bluetoothd﹕ 
external/bluetooth/bluez/android/gatt.c:connect_cb()

07-29 03:15:07.083  16843-16843/? E/bluetoothd﹕ gatt: connection failed 
HUP or ERR on socket: Connection reset by peer (104)

07-29 03:15:07.083  16843-16843/? D/bluetoothd﹕ 
external/bluetooth/bluez/android/gatt.c:device_set_state() gatt: Device 
94:01:C2:AB:46:05 state changed CONNECT READY -> DISCONNECTED


Symptoms:
- The connection request times out.
- bt_io_accept() is being called but the accept_cb (=connect_cb) only 
gets called when the request times out.
- the device is stuck in the CONNECT READY state and never reaches the 
CONNECTED state


Any ideas how I could analyze/solve that problem? I'm stuck on this for 
many hours already...

Thanks!

Florian

Re: Problems with incoming connection request on Nexus 4

[Marcel Holtmann]

Hi Florian,

> I'm currently testing my code on my Nexus 4 device. Multi-Advertising works nicely but I can't get the device to accept incoming connection requests while in peripheral mode. I'm using Nordic's nRF Master Control app on my Samsung S4 in the central role for testing.
> 
> Here some sample debug output. When launching the connection request I get:
> 
> 07-29 03:14:36.816  16843-16843/? I/bluetoothd﹕
> mgmt_if: > 0b 00 00 00 1e 00 05 46 ab c2 01 94 00 00 00 00
> .......F........
> 
> 07-29 03:14:36.816  16843-16843/? I/bluetoothd﹕
> mgmt_if:   00 11 00 0b 09 66 67 2d 73 61 6d 73 75 6e 67 04
> .....fg-samsung.
> 
> 07-29 03:14:36.816  16843-16843/? I/bluetoothd﹕
> mgmt_if:   0d 0c 02 5a
> ...Z
> 
> 07-29 03:14:36.816  16843-16843/? I/bluetoothd﹕
> mgmt_if: [0x0000] event 0x000b
> 
> 07-29 03:14:36.816  16843-16843/? D/bluetoothd﹕
> external/bluetooth/bluez/android/bluetooth.c:mgmt_device_connected_event() 94:01:C2:AB:46:05 type 0
> 
> 07-29 03:14:36.829  16817-16875/com.android.bluetooth D/BlueZ﹕ external/bluetooth/bluez/android/hal-bluetooth.c:handle_acl_state_changed() state 0
> 
> 07-29 03:14:37.100  16843-16843/? D/bluetoothd﹕ external/bluetooth/bluez/android/gatt.c:connect_confirm()
> 
> 07-29 03:14:37.100  16843-16843/? D/bluetoothd﹕ external/bluetooth/bluez/android/gatt.c:device_set_state() gatt: Device 94:01:C2:AB:46:05 state changed DISCONNECTED -> CONNECT READY
> 
> 
> And then after the timeout:
> 
> 07-29 03:15:07.083  16843-16843/? D/bluetoothd﹕ external/bluetooth/bluez/android/gatt.c:connect_cb()
> 
> 07-29 03:15:07.083  16843-16843/? E/bluetoothd﹕ gatt: connection failed HUP or ERR on socket: Connection reset by peer (104)
> 
> 07-29 03:15:07.083  16843-16843/? D/bluetoothd﹕ external/bluetooth/bluez/android/gatt.c:device_set_state() gatt: Device 94:01:C2:AB:46:05 state changed CONNECT READY -> DISCONNECTED
> 
> 
> Symptoms:
> - The connection request times out.
> - bt_io_accept() is being called but the accept_cb (=connect_cb) only gets called when the request times out.
> - the device is stuck in the CONNECT READY state and never reaches the CONNECTED state
> 
> 
> Any ideas how I could analyze/solve that problem? I'm stuck on this for many hours already...

what does btmon actually tell you about what is going on with HCI. Remember that a connection disables advertising in the controller.

Regards

Marcel

Re: Problems with incoming connection request on Nexus 4

[Florian Grandel]

Hi Marcel,

 >> Symptoms:
>> - The connection request times out.
>> - bt_io_accept() is being called but the accept_cb (=connect_cb) only gets called when the request times out.
>> - the device is stuck in the CONNECT READY state and never reaches the CONNECTED state
>>
>>
>> Any ideas how I could analyze/solve that problem? I'm stuck on this for many hours already...
>
> what does btmon actually tell you about what is going on with HCI.

= New Index: 10:68:3F:56:AD:35 (BR/EDR,UNKNOWN,hci0)            [hci0] 
0.629837
@ Advertising Added: 1
< HCI Command: LE Set Advertising Para.. (0x08|0x0006) plen 15  [hci0] 
4.398493
         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                     [hci0] 
4.401392
       LE Set Advertising Parameters (0x08|0x0006) ncmd 1
         Status: Success (0x00)
< HCI Command: LE Set Advertise Enable (0x08|0x000a) plen 1     [hci0] 
4.401484
         Advertising: Enabled (0x01)
 > HCI Event: Command Complete (0x0e) plen 4                     [hci0] 
4.402277
       LE Set Advertise Enable (0x08|0x000a) ncmd 1
         Status: Success (0x00)

There is no connection related HCI activity going on at all on the Nexus 
4 side. You can see from the debug logs that I sent before, that the 
connection is being initiated correctly. The bt_io_accept() call does 
return without error, just the accept callback never gets called. To me 
it seems as if the Nexus4 was not responding to the incoming connect 
request.

 > Remember that a connection disables advertising in the controller.

The advertising being aborted on connect is not a problem. The 
advertising part works flawlessly. Connecting

Florian

Re: Problems with incoming connection request on Nexus 4

[Marcel Holtmann]

Hi Florian,

> >> Symptoms:
>>> - The connection request times out.
>>> - bt_io_accept() is being called but the accept_cb (=connect_cb) only gets called when the request times out.
>>> - the device is stuck in the CONNECT READY state and never reaches the CONNECTED state
>>> 
>>> 
>>> Any ideas how I could analyze/solve that problem? I'm stuck on this for many hours already...
>> 
>> what does btmon actually tell you about what is going on with HCI.
> 
> = New Index: 10:68:3F:56:AD:35 (BR/EDR,UNKNOWN,hci0)            [hci0] 0.629837
> @ Advertising Added: 1
> < HCI Command: LE Set Advertising Para.. (0x08|0x0006) plen 15  [hci0] 4.398493
>        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                     [hci0] 4.401392
>      LE Set Advertising Parameters (0x08|0x0006) ncmd 1
>        Status: Success (0x00)
> < HCI Command: LE Set Advertise Enable (0x08|0x000a) plen 1     [hci0] 4.401484
>        Advertising: Enabled (0x01)
> > HCI Event: Command Complete (0x0e) plen 4                     [hci0] 4.402277
>      LE Set Advertise Enable (0x08|0x000a) ncmd 1
>        Status: Success (0x00)
> 
> There is no connection related HCI activity going on at all on the Nexus 4 side. You can see from the debug logs that I sent before, that the connection is being initiated correctly. The bt_io_accept() call does return without error, just the accept callback never gets called. To me it seems as if the Nexus4 was not responding to the incoming connect request.

we are advertising now. If the HCI traffic stays this way, then we are basically waiting for the central to connect to us. It is up to your Nexus 4 to connect.

If it would connect, then you would see an LE Connect Complete event indicated that the connection has been established.

Regards

Marcel

Re: Problems with incoming connection request on Nexus 4

[Florian Grandel]

Hi Marcel and Szymon,

On 07/30/2015 02:25 PM, Marcel Holtmann wrote:
> Hi Florian,
>
>>>> Symptoms:
>>>> - The connection request times out.
>>>> - bt_io_accept() is being called but the accept_cb (=connect_cb) only gets called when the request times out.
>>>> - the device is stuck in the CONNECT READY state and never reaches the CONNECTED state
>>>>
>>>>
>>>> Any ideas how I could analyze/solve that problem? I'm stuck on this for many hours already...
>>>
>>> what does btmon actually tell you about what is going on with HCI.
>>
>> = New Index: 10:68:3F:56:AD:35 (BR/EDR,UNKNOWN,hci0)            [hci0] 0.629837
>> @ Advertising Added: 1
>> < HCI Command: LE Set Advertising Para.. (0x08|0x0006) plen 15  [hci0] 4.398493
>>         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                     [hci0] 4.401392
>>       LE Set Advertising Parameters (0x08|0x0006) ncmd 1
>>         Status: Success (0x00)
>> < HCI Command: LE Set Advertise Enable (0x08|0x000a) plen 1     [hci0] 4.401484
>>         Advertising: Enabled (0x01)
>>> HCI Event: Command Complete (0x0e) plen 4                     [hci0] 4.402277
>>       LE Set Advertise Enable (0x08|0x000a) ncmd 1
>>         Status: Success (0x00)
>>
>> There is no connection related HCI activity going on at all on the Nexus 4 side. You can see from the debug logs that I sent before, that the connection is being initiated correctly. The bt_io_accept() call does return without error, just the accept callback never gets called. To me it seems as if the Nexus4 was not responding to the incoming connect request.
>
> we are advertising now. If the HCI traffic stays this way, then we are basically waiting for the central to connect to us. It is up to your Nexus 4 to connect.
>
> If it would connect, then you would see an LE Connect Complete event indicated that the connection has been established.

Sorry, I left out the actual connection part the first time. Here it is:

= New Index: 10:68:3F:56:AD:35 (BR/EDR,UNKNOWN,hci0)            [hci0] 
0.248759
 > HCI Event: Connect Request (0x04) plen 10                     [hci0] 
9.147279
         Address: 94:01:C2:AB:46:05 (OUI 94-01-C2)
         Class: 0x5a020c
           Major class: Phone (cellular, cordless, payphone, modem)
           Minor class: Smart phone
           Networking (LAN, Ad hoc)
           Capturing (Scanner, Microphone)
           Object Transfer (v-Inbox, v-Folder)
           Telephony (Cordless telephony, Modem, Headset)
         Link type: ACL (0x01)
< HCI Command: Accept Connection Request (0x01|0x0009) plen 7   [hci0] 
9.147523
         Address: 94:01:C2:AB:46:05 (OUI 94-01-C2)
         Role: Master (0x00)
 > HCI Event: Command Status (0x0f) plen 4                       [hci0] 
9.148347
       Accept Connection Request (0x01|0x0009) ncmd 1
         Status: Success (0x00)
 > HCI Event: Role Change (0x12) plen 8                          [hci0] 
9.402337
         Status: Success (0x00)
         Address: 94:01:C2:AB:46:05 (OUI 94-01-C2)
         Role: Master (0x00)
 > HCI Event: Connect Complete (0x03) plen 11                    [hci0] 
9.415339
         Status: Success (0x00)
         Handle: 4
         Address: 94:01:C2:AB:46:05 (OUI 94-01-C2)
         Link type: ACL (0x01)
         Encryption: Disabled (0x00)
 > HCI Event: Max Slots Change (0x1b) plen 3                     [hci0] 
9.417506
         Handle: 4
         Max slots: 5
< HCI Command: Read Remote Supported Fe.. (0x01|0x001b) plen 2  [hci0] 
9.418360
         Handle: 4
 > HCI Event: Command Status (0x0f) plen 4                       [hci0] 
9.418910
       Read Remote Supported Features (0x01|0x001b) ncmd 1
         Status: Success (0x00)
 > HCI Event: Read Remote Supported Features (0x0b) plen 11      [hci0] 
9.423793
         Status: Success (0x00)
         Handle: 4
         Features: 0xbf 0xfe 0xcf 0xff 0xdf 0xff 0x7b 0x87
           3 slot packets
           5 slot packets
           Encryption
           Slot offset
           Timing accuracy
           Role switch
           Sniff mode
           Power control requests
           Channel quality driven data rate (CQDDR)
           SCO link
           HV2 packets
           HV3 packets
           u-law log synchronous data
           A-law log synchronous data
           CVSD synchronous data
           Paging parameter negotiation
           Power control
           Transparent synchronous data
           Flow control lag (most significant bit)
           Broadcast Encryption
           Enhanced Data Rate ACL 2 Mbps mode
           Enhanced Data Rate ACL 3 Mbps mode
           Enhanced inquiry scan
           Interlaced inquiry scan
           Interlaced page scan
           RSSI with inquiry results
           Extended SCO link (EV3 packets)
           EV4 packets
           EV5 packets
           AFH capable slave
           AFH classification slave
           LE Supported (Controller)
           3-slot Enhanced Data Rate ACL packets
           5-slot Enhanced Data Rate ACL packets
           Sniff subrating
           Pause encryption
           AFH capable master
           AFH classification master
           Enhanced Data Rate eSCO 2 Mbps mode
           Enhanced Data Rate eSCO 3 Mbps mode
           3-slot Enhanced Data Rate eSCO packets
           Extended Inquiry Response
           Simultaneous LE and BR/EDR (Controller)
           Secure Simple Pairing
           Encapsulated PDU
           Erroneous Data Reporting
           Non-flushable Packet Boundary Flag
           Link Supervision Timeout Changed Event
           Inquiry TX Power Level
           Enhanced Power Control
           Extended features
           Unknown features (0x0000000401000000)
< HCI Command: Read Remote Extended Fea.. (0x01|0x001c) plen 3  [hci0] 
9.423946
         Handle: 4
         Page: 1
 > HCI Event: Command Status (0x0f) plen 4                       [hci0] 
9.424373
       Read Remote Extended Features (0x01|0x001c) ncmd 1
         Status: Success (0x00)
 > ACL Data RX: Handle 4 flags 0x02 dlen 10                      [hci0] 
9.426235
       L2CAP: Information Request (0x0a) ident 2 len 2
         Type: Extended features supported (0x0002)
 > HCI Event: Read Remote Extended Features (0x23) plen 13       [hci0] 
9.427517
         Status: Success (0x00)
         Handle: 4
         Page: 1/1
         Features: 0x03 0x00 0x00 0x00 0x00 0x00 0x00 0x00
           Secure Simple Pairing (Host Support)
           LE Supported (Host)
< HCI Command: Remote Name Request (0x01|0x0019) plen 10        [hci0] 
9.427944
         Address: 94:01:C2:AB:46:05 (OUI 94-01-C2)
         Page scan repetition mode: R2 (0x02)
         Page scan mode: Mandatory (0x00)
         Clock offset: 0x0000
< ACL Data TX: Handle 4 flags 0x00 dlen 10                      [hci0] 
9.428005
       L2CAP: Information Request (0x0a) ident 1 len 2
         Type: Extended features supported (0x0002)
< ACL Data TX: Handle 4 flags 0x00 dlen 16                      [hci0] 
9.428066
       L2CAP: Information Response (0x0b) ident 2 len 8
         Type: Extended features supported (0x0002)
         Result: Success (0x0000)
         Features: 0x000002b8
           Enhanced Retransmission Mode
           Streaming Mode
           FCS Option
           Fixed Channels
           Unicast Connectionless Data Reception
 > HCI Event: Command Status (0x0f) plen 4                       [hci0] 
9.428554
       Remote Name Request (0x01|0x0019) ncmd 1
         Status: Success (0x00)
 > HCI Event: Remote Name Req Complete (0x07) plen 255           [hci0] 
9.432522
         Status: Success (0x00)
         Address: 94:01:C2:AB:46:05 (OUI 94-01-C2)
         Name: fg-samsung
 > HCI Event: Number of Completed Packets (0x13) plen 5          [hci0] 
9.433102
         Num handles: 1
         Handle: 4
         Count: 1
@ Device Connected: 94:01:C2:AB:46:05 (0) flags 0x0000
         0b 09 66 67 2d 73 61 6d 73 75 6e 67 04 0d 0c 02  ..fg-samsung....
         5a                                               Z
 > HCI Event: Link Key Request (0x17) plen 6                     [hci0] 
9.558724
         Address: 94:01:C2:AB:46:05 (OUI 94-01-C2)
< HCI Command: Link Key Request Reply (0x01|0x000b) plen 22     [hci0] 
9.558785
         Address: 94:01:C2:AB:46:05 (OUI 94-01-C2)
         Link key: 80a94e676e77657ad219b275c1c2964a
 > HCI Event: Command Complete (0x0e) plen 10                    [hci0] 
9.558998
       Link Key Request Reply (0x01|0x000b) ncmd 1
         Status: Success (0x00)
         Address: 94:01:C2:AB:46:05 (OUI 94-01-C2)
 > HCI Event: Number of Completed Packets (0x13) plen 5          [hci0] 
9.559304
         Num handles: 1
         Handle: 4
         Count: 1
 > ACL Data RX: Handle 4 flags 0x02 dlen 16                      [hci0] 
9.559944
       L2CAP: Information Response (0x0b) ident 1 len 8
         Type: Extended features supported (0x0002)
         Result: Success (0x0000)
         Features: 0x000000b8
           Enhanced Retransmission Mode
           Streaming Mode
           FCS Option
           Fixed Channels
< ACL Data TX: Handle 4 flags 0x00 dlen 10                      [hci0] 
9.560006
       L2CAP: Information Request (0x0a) ident 2 len 2
         Type: Fixed channels supported (0x0003)
 > ACL Data RX: Handle 4 flags 0x02 dlen 10                      [hci0] 
9.562447
       L2CAP: Information Request (0x0a) ident 3 len 2
         Type: Fixed channels supported (0x0003)
< ACL Data TX: Handle 4 flags 0x00 dlen 20                      [hci0] 
9.562508
       L2CAP: Information Response (0x0b) ident 3 len 12
         Type: Fixed channels supported (0x0003)
         Result: Success (0x0000)
         Channels: 0x0000000000000086
           L2CAP Signaling (BR/EDR)
           Connectionless reception
           Security Manager (BR/EDR)
 > HCI Event: Number of Completed Packets (0x13) plen 5          [hci0] 
9.564309
         Num handles: 1
         Handle: 4
         Count: 1
 > HCI Event: Number of Completed Packets (0x13) plen 5          [hci0] 
9.586802
         Num handles: 1
         Handle: 4
         Count: 1
 > HCI Event: Encryption Change (0x08) plen 4                    [hci0] 
9.680012
         Status: Success (0x00)
         Handle: 4
         Encryption: Enabled with E0 (0x01)
< HCI Command: Read Encryption Key Size (0x05|0x0008) plen 2    [hci0] 
9.680042
         Handle: 4
 > HCI Event: Command Complete (0x0e) plen 7                     [hci0] 
9.680256
       Read Encryption Key Size (0x05|0x0008) ncmd 1
         Status: Success (0x00)
         Handle: 4
         Key size: 16
 > ACL Data RX: Handle 4 flags 0x02 dlen 20                      [hci0] 
9.682453
       L2CAP: Information Response (0x0b) ident 2 len 12
         Type: Fixed channels supported (0x0003)
         Result: Success (0x0000)
         Channels: 0x0000000000000052
           L2CAP Signaling (BR/EDR)
           Attribute Protocol
           Security Manager (LE)
 > ACL Data RX: Handle 4 flags 0x02 dlen 12                      [hci0] 
9.683674
       L2CAP: Connection Request (0x02) ident 4 len 4
         PSM: 31 (0x001f)
         Source CID: 66
< ACL Data TX: Handle 4 flags 0x00 dlen 16                      [hci0] 
9.683766
       L2CAP: Connection Response (0x03) ident 4 len 8
         Destination CID: 64
         Source CID: 66
         Result: Connection pending (0x0001)
         Status: Authorization pending (0x0002)
< ACL Data TX: Handle 4 flags 0x00 dlen 16                      [hci0] 
9.686970
       L2CAP: Connection Response (0x03) ident 4 len 8
         Destination CID: 64
         Source CID: 66
         Result: Connection successful (0x0000)
         Status: No further information available (0x0000)
< ACL Data TX: Handle 4 flags 0x00 dlen 23                      [hci0] 
9.687031
       L2CAP: Configure Request (0x04) ident 3 len 15
         Destination CID: 66
         Flags: 0x0000
         Option: Retransmission and Flow Control (0x04) [mandatory]
           Mode: Basic (0x00)
           TX window size: 0
           Max transmit: 0
           Retransmission timeout: 0
           Monitor timeout: 0
           Maximum PDU size: 0
 > HCI Event: Number of Completed Packets (0x13) plen 5          [hci0] 
9.686787
         Num handles: 1
         Handle: 4
         Count: 1
 > HCI Event: Number of Completed Packets (0x13) plen 5          [hci0] 
9.689687
         Num handles: 1
         Handle: 4
         Count: 1
 > HCI Event: Number of Completed Packets (0x13) plen 5          [hci0] 
9.690602
         Num handles: 1
         Handle: 4
         Count: 1
 > ACL Data RX: Handle 4 flags 0x02 dlen 12                     [hci0] 
39.623824
       L2CAP: Disconnection Request (0x06) ident 5 len 4
         Destination CID: 64
         Source CID: 66
< ACL Data TX: Handle 4 flags 0x00 dlen 12                     [hci0] 
39.624037
       L2CAP: Disconnection Response (0x07) ident 5 len 4
         Destination CID: 64
         Source CID: 66
 > HCI Event: Number of Completed Packets (0x13) plen 5         [hci0] 
39.626815
         Num handles: 1
         Handle: 4
         Count: 1
< HCI Command: Read Clock Offset (0x01|0x001f) plen 2          [hci0] 
43.626998
         Handle: 4
 > HCI Event: Command Status (0x0f) plen 4                      [hci0] 
43.627547
       Read Clock Offset (0x01|0x001f) ncmd 1
         Status: Success (0x00)
< HCI Command: Disconnect (0x01|0x0006) plen 3                 [hci0] 
43.627791
         Handle: 4
         Reason: Remote User Terminated Connection (0x13)
 > HCI Event: Command Status (0x0f) plen 4                      [hci0] 
43.628249
       Disconnect (0x01|0x0006) ncmd 1
         Status: Success (0x00)
 > HCI Event: Read Clock Offset Complete (0x1c) plen 5          [hci0] 
43.637192
         Status: Connection Terminated By Local Host (0x16)
         Handle: 4
         Clock offset: 0x0000
 > HCI Event: Disconnect Complete (0x05) plen 4                 [hci0] 
43.637283
         Status: Success (0x00)
         Handle: 4
         Reason: Connection Terminated By Local Host (0x16)
@ Device Disconnected: 94:01:C2:AB:46:05 (0) reason 2

Can you seen anything from this?

Thanks!

Florian

Re: Problems with incoming connection request on Nexus 4

[Marcel Holtmann]

Hi Florian,

>>>>> Symptoms:
>>>>> - The connection request times out.
>>>>> - bt_io_accept() is being called but the accept_cb (=connect_cb) only gets called when the request times out.
>>>>> - the device is stuck in the CONNECT READY state and never reaches the CONNECTED state
>>>>> 
>>>>> 
>>>>> Any ideas how I could analyze/solve that problem? I'm stuck on this for many hours already...
>>>> 
>>>> what does btmon actually tell you about what is going on with HCI.
>>> 
>>> = New Index: 10:68:3F:56:AD:35 (BR/EDR,UNKNOWN,hci0)            [hci0] 0.629837
>>> @ Advertising Added: 1
>>> < HCI Command: LE Set Advertising Para.. (0x08|0x0006) plen 15  [hci0] 4.398493
>>>        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                     [hci0] 4.401392
>>>      LE Set Advertising Parameters (0x08|0x0006) ncmd 1
>>>        Status: Success (0x00)
>>> < HCI Command: LE Set Advertise Enable (0x08|0x000a) plen 1     [hci0] 4.401484
>>>        Advertising: Enabled (0x01)
>>>> HCI Event: Command Complete (0x0e) plen 4                     [hci0] 4.402277
>>>      LE Set Advertise Enable (0x08|0x000a) ncmd 1
>>>        Status: Success (0x00)
>>> 
>>> There is no connection related HCI activity going on at all on the Nexus 4 side. You can see from the debug logs that I sent before, that the connection is being initiated correctly. The bt_io_accept() call does return without error, just the accept callback never gets called. To me it seems as if the Nexus4 was not responding to the incoming connect request.
>> 
>> we are advertising now. If the HCI traffic stays this way, then we are basically waiting for the central to connect to us. It is up to your Nexus 4 to connect.
>> 
>> If it would connect, then you would see an LE Connect Complete event indicated that the connection has been established.
> 
> Sorry, I left out the actual connection part the first time. Here it is:
> 
> = New Index: 10:68:3F:56:AD:35 (BR/EDR,UNKNOWN,hci0)            [hci0] 0.248759
> > HCI Event: Connect Request (0x04) plen 10                     [hci0] 9.147279
>        Address: 94:01:C2:AB:46:05 (OUI 94-01-C2)
>        Class: 0x5a020c
>          Major class: Phone (cellular, cordless, payphone, modem)
>          Minor class: Smart phone
>          Networking (LAN, Ad hoc)
>          Capturing (Scanner, Microphone)
>          Object Transfer (v-Inbox, v-Folder)
>          Telephony (Cordless telephony, Modem, Headset)
>        Link type: ACL (0x01)

this is a BR/EDR connection. So it seems even while it sees you advertise on LE, it then connects using BR/EDR. Since Bluetooth 4.0 did not allow BR/EDR and LE at the same time. Only Bluetooth 4.1 relaxed this.

But it is hilarious that your phone stack sees an LE advertising and then connects to you over BR/EDR.

Regards

Marcel

Re: Problems with incoming connection request on Nexus 4

[Adam Moore]

[-- Attachment #1: Type: text/plain, Size: 3854 bytes --]

That problem sounds familiar - I think I've heard of that happening if the
BR/EDR Not Supported bit is cleared in your advertising data's flags. Maybe
it just needs to be set.
On Thu, Jul 30, 2015 at 09:10 Marcel Holtmann <marcel@holtmann.org> wrote:

> Hi Florian,
>
> >>>>> Symptoms:
> >>>>> - The connection request times out.
> >>>>> - bt_io_accept() is being called but the accept_cb (=connect_cb)
> only gets called when the request times out.
> >>>>> - the device is stuck in the CONNECT READY state and never reaches
> the CONNECTED state
> >>>>>
> >>>>>
> >>>>> Any ideas how I could analyze/solve that problem? I'm stuck on this
> for many hours already...
> >>>>
> >>>> what does btmon actually tell you about what is going on with HCI.
> >>>
> >>> = New Index: 10:68:3F:56:AD:35 (BR/EDR,UNKNOWN,hci0)            [hci0]
> 0.629837
> >>> @ Advertising Added: 1
> >>> < HCI Command: LE Set Advertising Para.. (0x08|0x0006) plen 15  [hci0]
> 4.398493
> >>>        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                     [hci0]
> 4.401392
> >>>      LE Set Advertising Parameters (0x08|0x0006) ncmd 1
> >>>        Status: Success (0x00)
> >>> < HCI Command: LE Set Advertise Enable (0x08|0x000a) plen 1     [hci0]
> 4.401484
> >>>        Advertising: Enabled (0x01)
> >>>> HCI Event: Command Complete (0x0e) plen 4                     [hci0]
> 4.402277
> >>>      LE Set Advertise Enable (0x08|0x000a) ncmd 1
> >>>        Status: Success (0x00)
> >>>
> >>> There is no connection related HCI activity going on at all on the
> Nexus 4 side. You can see from the debug logs that I sent before, that the
> connection is being initiated correctly. The bt_io_accept() call does
> return without error, just the accept callback never gets called. To me it
> seems as if the Nexus4 was not responding to the incoming connect request.
> >>
> >> we are advertising now. If the HCI traffic stays this way, then we are
> basically waiting for the central to connect to us. It is up to your Nexus
> 4 to connect.
> >>
> >> If it would connect, then you would see an LE Connect Complete event
> indicated that the connection has been established.
> >
> > Sorry, I left out the actual connection part the first time. Here it is:
> >
> > = New Index: 10:68:3F:56:AD:35 (BR/EDR,UNKNOWN,hci0)            [hci0]
> 0.248759
> > > HCI Event: Connect Request (0x04) plen 10                     [hci0]
> 9.147279
> >        Address: 94:01:C2:AB:46:05 (OUI 94-01-C2)
> >        Class: 0x5a020c
> >          Major class: Phone (cellular, cordless, payphone, modem)
> >          Minor class: Smart phone
> >          Networking (LAN, Ad hoc)
> >          Capturing (Scanner, Microphone)
> >          Object Transfer (v-Inbox, v-Folder)
> >          Telephony (Cordless telephony, Modem, Headset)
> >        Link type: ACL (0x01)
>
> this is a BR/EDR connection. So it seems even while it sees you advertise
> on LE, it then connects using BR/EDR. Since Bluetooth 4.0 did not allow
> BR/EDR and LE at the same time. Only Bluetooth 4.1 relaxed this.
>
> But it is hilarious that your phone stack sees an LE advertising and then
> connects to you over BR/EDR.
>
> Regards
>
> Marcel
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-bluetooth"
> in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

[-- Attachment #2: Type: text/html, Size: 4932 bytes --]

Re: Problems with incoming connection request on Nexus 4

[Lukasz Rymanowski]

Hi Florian,

On Thu, Jul 30, 2015 at 6:00 PM, Marcel Holtmann <marcel@holtmann.org> wrot=
e:
>
> Hi Florian,
>
> >>>>> Symptoms:
> >>>>> - The connection request times out.
> >>>>> - bt_io_accept() is being called but the accept_cb (=3Dconnect_cb) =
only gets called when the request times out.
> >>>>> - the device is stuck in the CONNECT READY state and never reaches =
the CONNECTED state
> >>>>>
> >>>>>
> >>>>> Any ideas how I could analyze/solve that problem? I'm stuck on this=
 for many hours already...
> >>>>
> >>>> what does btmon actually tell you about what is going on with HCI.
> >>>
> >>> =3D New Index: 10:68:3F:56:AD:35 (BR/EDR,UNKNOWN,hci0)            [hc=
i0] 0.629837
> >>> @ Advertising Added: 1
> >>> < HCI Command: LE Set Advertising Para.. (0x08|0x0006) plen 15  [hci0=
] 4.398493
> >>>        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 Requ=
est from Any (0x00)
> >>>> HCI Event: Command Complete (0x0e) plen 4                     [hci0]=
 4.401392
> >>>      LE Set Advertising Parameters (0x08|0x0006) ncmd 1
> >>>        Status: Success (0x00)
> >>> < HCI Command: LE Set Advertise Enable (0x08|0x000a) plen 1     [hci0=
] 4.401484
> >>>        Advertising: Enabled (0x01)
> >>>> HCI Event: Command Complete (0x0e) plen 4                     [hci0]=
 4.402277
> >>>      LE Set Advertise Enable (0x08|0x000a) ncmd 1
> >>>        Status: Success (0x00)
> >>>
> >>> There is no connection related HCI activity going on at all on the Ne=
xus 4 side. You can see from the debug logs that I sent before, that the co=
nnection is being initiated correctly. The bt_io_accept() call does return =
without error, just the accept callback never gets called. To me it seems a=
s if the Nexus4 was not responding to the incoming connect request.
> >>
> >> we are advertising now. If the HCI traffic stays this way, then we are=
 basically waiting for the central to connect to us. It is up to your Nexus=
 4 to connect.
> >>
> >> If it would connect, then you would see an LE Connect Complete event i=
ndicated that the connection has been established.


Actually I recall  that we face the same on Nexus 4 being in
peripheral role some time ago. That time our analyzes shows that it is
chip or firmware issue. Unfortunately I don't remember if we got rid
of it or not. If you have latest firmware and issue is still there,
that's a bad luck.

>
> >
> > Sorry, I left out the actual connection part the first time. Here it is=
:
> >
> > =3D New Index: 10:68:3F:56:AD:35 (BR/EDR,UNKNOWN,hci0)            [hci0=
] 0.248759
> > > HCI Event: Connect Request (0x04) plen 10                     [hci0] =
9.147279
> >        Address: 94:01:C2:AB:46:05 (OUI 94-01-C2)
> >        Class: 0x5a020c
> >          Major class: Phone (cellular, cordless, payphone, modem)
> >          Minor class: Smart phone
> >          Networking (LAN, Ad hoc)
> >          Capturing (Scanner, Microphone)
> >          Object Transfer (v-Inbox, v-Folder)
> >          Telephony (Cordless telephony, Modem, Headset)
> >        Link type: ACL (0x01)
>
> this is a BR/EDR connection. So it seems even while it sees you advertise=
 on LE, it then connects using BR/EDR. Since Bluetooth 4.0 did not allow BR=
/EDR and LE at the same time. Only Bluetooth 4.1 relaxed this.
>
> But it is hilarious that your phone stack sees an LE advertising and then=
 connects to you over BR/EDR.
>
> Regards
>
> Marcel
>

=C5=81ukasz

>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-bluetooth=
" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Problems with incoming connection request on Nexus 4

[Adam Moore]

I just saw this happen on a Nexus 9 (running build LMY47X/5.1.1) when it
successfully established a BR/EDR connection to my peripheral running
Linux 3.14 and BlueZ 5.32.

After restarting BT from Settings I started getting LE connections.

I have also have the BR/EDR Not Supported bit set in the peripheral's
advertising flags.

I'll keep an eye on this too.

On 7/31/15, 12:47 PM, "linux-bluetooth-owner@vger.kernel.org on behalf of
Lukasz Rymanowski" <linux-bluetooth-owner@vger.kernel.org on behalf of
lukasz.rymanowski@gmail.com> wrote:

>Hi Florian,
>
>On Thu, Jul 30, 2015 at 6:00 PM, Marcel Holtmann <marcel@holtmann.org>
>wrote:
>>
>> Hi Florian,
>>
>> >>>>> Symptoms:
>> >>>>> - The connection request times out.
>> >>>>> - bt_io_accept() is being called but the accept_cb (=3Dconnect_cb)
>>only gets called when the request times out.
>> >>>>> - the device is stuck in the CONNECT READY state and never
>>reaches the CONNECTED state
>> >>>>>
>> >>>>>
>> >>>>> Any ideas how I could analyze/solve that problem? I'm stuck on
>>this for many hours already...
>> >>>>
>> >>>> what does btmon actually tell you about what is going on with HCI.
>> >>>
>> >>> =3D New Index: 10:68:3F:56:AD:35 (BR/EDR,UNKNOWN,hci0)
>>[hci0] 0.629837
>> >>> @ Advertising Added: 1
>> >>> < HCI Command: LE Set Advertising Para.. (0x08|0x0006) plen 15
>>[hci0] 4.398493
>> >>>        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
>>[hci0] 4.401392
>> >>>      LE Set Advertising Parameters (0x08|0x0006) ncmd 1
>> >>>        Status: Success (0x00)
>> >>> < HCI Command: LE Set Advertise Enable (0x08|0x000a) plen 1
>>[hci0] 4.401484
>> >>>        Advertising: Enabled (0x01)
>> >>>> HCI Event: Command Complete (0x0e) plen 4
>>[hci0] 4.402277
>> >>>      LE Set Advertise Enable (0x08|0x000a) ncmd 1
>> >>>        Status: Success (0x00)
>> >>>
>> >>> There is no connection related HCI activity going on at all on the
>>Nexus 4 side. You can see from the debug logs that I sent before, that
>>the connection is being initiated correctly. The bt_io_accept() call
>>does return without error, just the accept callback never gets called.
>>To me it seems as if the Nexus4 was not responding to the incoming
>>connect request.
>> >>
>> >> we are advertising now. If the HCI traffic stays this way, then we
>>are basically waiting for the central to connect to us. It is up to your
>>Nexus 4 to connect.
>> >>
>> >> If it would connect, then you would see an LE Connect Complete event
>>indicated that the connection has been established.
>
>
>Actually I recall  that we face the same on Nexus 4 being in
>peripheral role some time ago. That time our analyzes shows that it is
>chip or firmware issue. Unfortunately I don't remember if we got rid
>of it or not. If you have latest firmware and issue is still there,
>that's a bad luck.
>
>>
>> >
>> > Sorry, I left out the actual connection part the first time. Here it
>>is:
>> >
>> > =3D New Index: 10:68:3F:56:AD:35 (BR/EDR,UNKNOWN,hci0)
>>[hci0] 0.248759
>> > > HCI Event: Connect Request (0x04) plen 10
>>[hci0] 9.147279
>> >        Address: 94:01:C2:AB:46:05 (OUI 94-01-C2)
>> >        Class: 0x5a020c
>> >          Major class: Phone (cellular, cordless, payphone, modem)
>> >          Minor class: Smart phone
>> >          Networking (LAN, Ad hoc)
>> >          Capturing (Scanner, Microphone)
>> >          Object Transfer (v-Inbox, v-Folder)
>> >          Telephony (Cordless telephony, Modem, Headset)
>> >        Link type: ACL (0x01)
>>
>> this is a BR/EDR connection. So it seems even while it sees you
>>advertise on LE, it then connects using BR/EDR. Since Bluetooth 4.0 did
>>not allow BR/EDR and LE at the same time. Only Bluetooth 4.1 relaxed
>>this.
>>
>> But it is hilarious that your phone stack sees an LE advertising and
>>then connects to you over BR/EDR.
>>
>> Regards
>>
>> Marcel
>>
>
>=A3ukasz
>
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe
>>linux-bluetooth" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>--
>To unsubscribe from this list: send the line "unsubscribe
>linux-bluetooth" in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at  http://vger.kernel.org/majordomo-info.html


Statement of Confidentiality

The contents of this e-mail message and any attachments are confidential an=
d are intended solely for the addressee. The information may also be legall=
y privileged. This transmission is sent in trust, and the sole purpose of d=
elivery to the intended recipient. If you have received this transmission i=
n error, any use, reproduction or dissemination of this transmission is str=
ictly prohibited. If you are not the intended recipient, please immediately=
 notify the sender by reply e-mail or at 508.683.2500 and delete this messa=
ge and its attachments, if any.

Re: Problems with incoming connection request on Nexus 4

[Florian Grandel]

Hi Adam and Lukasz,

thanks for your feedback and insight. I'll let you know when I make 
progress.

Florian

On 08/01/2015 12:41 AM, Adam Moore wrote:
> I just saw this happen on a Nexus 9 (running build LMY47X/5.1.1) when it
> successfully established a BR/EDR connection to my peripheral running
> Linux 3.14 and BlueZ 5.32.
>
> After restarting BT from Settings I started getting LE connections.
>
> I have also have the BR/EDR Not Supported bit set in the peripheral's
> advertising flags.
>
> I'll keep an eye on this too.
>
> On 7/31/15, 12:47 PM, "linux-bluetooth-owner@vger.kernel.org on behalf of
> Lukasz Rymanowski" <linux-bluetooth-owner@vger.kernel.org on behalf of
> lukasz.rymanowski@gmail.com> wrote:
>
>> Hi Florian,
>>
>> On Thu, Jul 30, 2015 at 6:00 PM, Marcel Holtmann <marcel@holtmann.org>
>> wrote:
>>>
>>> Hi Florian,
>>>
>>>>>>>> Symptoms:
>>>>>>>> - The connection request times out.
>>>>>>>> - bt_io_accept() is being called but the accept_cb (=connect_cb)
>>> only gets called when the request times out.
>>>>>>>> - the device is stuck in the CONNECT READY state and never
>>> reaches the CONNECTED state
>>>>>>>>
>>>>>>>>
>>>>>>>> Any ideas how I could analyze/solve that problem? I'm stuck on
>>> this for many hours already...
>>>>>>>
>>>>>>> what does btmon actually tell you about what is going on with HCI.
>>>>>>
>>>>>> = New Index: 10:68:3F:56:AD:35 (BR/EDR,UNKNOWN,hci0)
>>> [hci0] 0.629837
>>>>>> @ Advertising Added: 1
>>>>>> < HCI Command: LE Set Advertising Para.. (0x08|0x0006) plen 15
>>> [hci0] 4.398493
>>>>>>         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
>>> [hci0] 4.401392
>>>>>>       LE Set Advertising Parameters (0x08|0x0006) ncmd 1
>>>>>>         Status: Success (0x00)
>>>>>> < HCI Command: LE Set Advertise Enable (0x08|0x000a) plen 1
>>> [hci0] 4.401484
>>>>>>         Advertising: Enabled (0x01)
>>>>>>> HCI Event: Command Complete (0x0e) plen 4
>>> [hci0] 4.402277
>>>>>>       LE Set Advertise Enable (0x08|0x000a) ncmd 1
>>>>>>         Status: Success (0x00)
>>>>>>
>>>>>> There is no connection related HCI activity going on at all on the
>>> Nexus 4 side. You can see from the debug logs that I sent before, that
>>> the connection is being initiated correctly. The bt_io_accept() call
>>> does return without error, just the accept callback never gets called.
>>> To me it seems as if the Nexus4 was not responding to the incoming
>>> connect request.
>>>>>
>>>>> we are advertising now. If the HCI traffic stays this way, then we
>>> are basically waiting for the central to connect to us. It is up to your
>>> Nexus 4 to connect.
>>>>>
>>>>> If it would connect, then you would see an LE Connect Complete event
>>> indicated that the connection has been established.
>>
>>
>> Actually I recall  that we face the same on Nexus 4 being in
>> peripheral role some time ago. That time our analyzes shows that it is
>> chip or firmware issue. Unfortunately I don't remember if we got rid
>> of it or not. If you have latest firmware and issue is still there,
>> that's a bad luck.
>>
>>>
>>>>
>>>> Sorry, I left out the actual connection part the first time. Here it
>>> is:
>>>>
>>>> = New Index: 10:68:3F:56:AD:35 (BR/EDR,UNKNOWN,hci0)
>>> [hci0] 0.248759
>>>>> HCI Event: Connect Request (0x04) plen 10
>>> [hci0] 9.147279
>>>>         Address: 94:01:C2:AB:46:05 (OUI 94-01-C2)
>>>>         Class: 0x5a020c
>>>>           Major class: Phone (cellular, cordless, payphone, modem)
>>>>           Minor class: Smart phone
>>>>           Networking (LAN, Ad hoc)
>>>>           Capturing (Scanner, Microphone)
>>>>           Object Transfer (v-Inbox, v-Folder)
>>>>           Telephony (Cordless telephony, Modem, Headset)
>>>>         Link type: ACL (0x01)
>>>
>>> this is a BR/EDR connection. So it seems even while it sees you
>>> advertise on LE, it then connects using BR/EDR. Since Bluetooth 4.0 did
>>> not allow BR/EDR and LE at the same time. Only Bluetooth 4.1 relaxed
>>> this.
>>>
>>> But it is hilarious that your phone stack sees an LE advertising and
>>> then connects to you over BR/EDR.
>>>
>>> Regards
>>>
>>> Marcel
>>>
>>
>> Łukasz
>>
>>>
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe
>>> linux-bluetooth" in
>>> the body of a message to majordomo@vger.kernel.org
>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>> --
>> To unsubscribe from this list: send the line "unsubscribe
>> linux-bluetooth" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
>
> Statement of Confidentiality
>
> The contents of this e-mail message and any attachments are confidential and are intended solely for the addressee. The information may also be legally privileged. This transmission is sent in trust, and the sole purpose of delivery to the intended recipient. If you have received this transmission in error, any use, reproduction or dissemination of this transmission is strictly prohibited. If you are not the intended recipient, please immediately notify the sender by reply e-mail or at 508.683.2500 and delete this message and its attachments, if any.
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

Re: Problems with incoming connection request on Nexus 4

[Adam Moore]

For some reason, my 5.28 devices were defaulting to LE mode even though I
didn't have a main.conf.  Being happy with this, I didn't ask questions
and likely incorrectly assumed it was because of what I was setting the
correct bits in the advertising data.

After updating to 5.32, my devices are defaulting to dual mode, according
to 'btmgmt info'.

After creating a main.conf and setting ControllerMode = le, my 5.32
devices are now seen as LE only.  This was probably the cause of my issue.
 Would like to know how I was able to get away without a main.conf before
though.

Will let you know if I figure that out.



On 8/1/15, 11:54 AM, "Florian Grandel" <fgrandel@gmail.com> wrote:

>Hi Adam and Lukasz,
>
>thanks for your feedback and insight. I'll let you know when I make
>progress.
>
>Florian
>
>On 08/01/2015 12:41 AM, Adam Moore wrote:
>> I just saw this happen on a Nexus 9 (running build LMY47X/5.1.1) when it
>> successfully established a BR/EDR connection to my peripheral running
>> Linux 3.14 and BlueZ 5.32.
>>
>> After restarting BT from Settings I started getting LE connections.
>>
>> I have also have the BR/EDR Not Supported bit set in the peripheral's
>> advertising flags.
>>
>> I'll keep an eye on this too.
>>
>> On 7/31/15, 12:47 PM, "linux-bluetooth-owner@vger.kernel.org on behalf
>>of
>> Lukasz Rymanowski" <linux-bluetooth-owner@vger.kernel.org on behalf of
>> lukasz.rymanowski@gmail.com> wrote:
>>
>>> Hi Florian,
>>>
>>> On Thu, Jul 30, 2015 at 6:00 PM, Marcel Holtmann <marcel@holtmann.org>
>>> wrote:
>>>>
>>>> Hi Florian,
>>>>
>>>>>>>>> Symptoms:
>>>>>>>>> - The connection request times out.
>>>>>>>>> - bt_io_accept() is being called but the accept_cb (=connect_cb)
>>>> only gets called when the request times out.
>>>>>>>>> - the device is stuck in the CONNECT READY state and never
>>>> reaches the CONNECTED state
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Any ideas how I could analyze/solve that problem? I'm stuck on
>>>> this for many hours already...
>>>>>>>>
>>>>>>>> what does btmon actually tell you about what is going on with HCI.
>>>>>>>
>>>>>>> = New Index: 10:68:3F:56:AD:35 (BR/EDR,UNKNOWN,hci0)
>>>> [hci0] 0.629837
>>>>>>> @ Advertising Added: 1
>>>>>>> < HCI Command: LE Set Advertising Para.. (0x08|0x0006) plen 15
>>>> [hci0] 4.398493
>>>>>>>         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
>>>> [hci0] 4.401392
>>>>>>>       LE Set Advertising Parameters (0x08|0x0006) ncmd 1
>>>>>>>         Status: Success (0x00)
>>>>>>> < HCI Command: LE Set Advertise Enable (0x08|0x000a) plen 1
>>>> [hci0] 4.401484
>>>>>>>         Advertising: Enabled (0x01)
>>>>>>>> HCI Event: Command Complete (0x0e) plen 4
>>>> [hci0] 4.402277
>>>>>>>       LE Set Advertise Enable (0x08|0x000a) ncmd 1
>>>>>>>         Status: Success (0x00)
>>>>>>>
>>>>>>> There is no connection related HCI activity going on at all on the
>>>> Nexus 4 side. You can see from the debug logs that I sent before, that
>>>> the connection is being initiated correctly. The bt_io_accept() call
>>>> does return without error, just the accept callback never gets called.
>>>> To me it seems as if the Nexus4 was not responding to the incoming
>>>> connect request.
>>>>>>
>>>>>> we are advertising now. If the HCI traffic stays this way, then we
>>>> are basically waiting for the central to connect to us. It is up to
>>>>your
>>>> Nexus 4 to connect.
>>>>>>
>>>>>> If it would connect, then you would see an LE Connect Complete event
>>>> indicated that the connection has been established.
>>>
>>>
>>> Actually I recall  that we face the same on Nexus 4 being in
>>> peripheral role some time ago. That time our analyzes shows that it is
>>> chip or firmware issue. Unfortunately I don't remember if we got rid
>>> of it or not. If you have latest firmware and issue is still there,
>>> that's a bad luck.
>>>
>>>>
>>>>>
>>>>> Sorry, I left out the actual connection part the first time. Here it
>>>> is:
>>>>>
>>>>> = New Index: 10:68:3F:56:AD:35 (BR/EDR,UNKNOWN,hci0)
>>>> [hci0] 0.248759
>>>>>> HCI Event: Connect Request (0x04) plen 10
>>>> [hci0] 9.147279
>>>>>         Address: 94:01:C2:AB:46:05 (OUI 94-01-C2)
>>>>>         Class: 0x5a020c
>>>>>           Major class: Phone (cellular, cordless, payphone, modem)
>>>>>           Minor class: Smart phone
>>>>>           Networking (LAN, Ad hoc)
>>>>>           Capturing (Scanner, Microphone)
>>>>>           Object Transfer (v-Inbox, v-Folder)
>>>>>           Telephony (Cordless telephony, Modem, Headset)
>>>>>         Link type: ACL (0x01)
>>>>
>>>> this is a BR/EDR connection. So it seems even while it sees you
>>>> advertise on LE, it then connects using BR/EDR. Since Bluetooth 4.0
>>>>did
>>>> not allow BR/EDR and LE at the same time. Only Bluetooth 4.1 relaxed
>>>> this.
>>>>
>>>> But it is hilarious that your phone stack sees an LE advertising and
>>>> then connects to you over BR/EDR.
>>>>
>>>> Regards
>>>>
>>>> Marcel
>>>>
>>>
>>> Łukasz
>>>
>>>>
>>>> --
>>>> To unsubscribe from this list: send the line "unsubscribe
>>>> linux-bluetooth" in
>>>> the body of a message to majordomo@vger.kernel.org
>>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe
>>> linux-bluetooth" in
>>> the body of a message to majordomo@vger.kernel.org
>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>
>>
>> Statement of Confidentiality
>>
>> The contents of this e-mail message and any attachments are
>>confidential and are intended solely for the addressee. The information
>>may also be legally privileged. This transmission is sent in trust, and
>>the sole purpose of delivery to the intended recipient. If you have
>>received this transmission in error, any use, reproduction or
>>dissemination of this transmission is strictly prohibited. If you are
>>not the intended recipient, please immediately notify the sender by
>>reply e-mail or at 508.683.2500 and delete this message and its
>>attachments, if any.
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe
>>linux-bluetooth" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>
>


Statement of Confidentiality

The contents of this e-mail message and any attachments are confidential and are intended solely for the addressee. The information may also be legally privileged. This transmission is sent in trust, and the sole purpose of delivery to the intended recipient. If you have received this transmission in error, any use, reproduction or dissemination of this transmission is strictly prohibited. If you are not the intended recipient, please immediately notify the sender by reply e-mail or at 508.683.2500 and delete this message and its attachments, if any.

Re: Problems with incoming connection request on Nexus 4

[Marcel Holtmann]

Hi Adam,

please refrain from top posting on this mailing list.

> For some reason, my 5.28 devices were defaulting to LE mode even though I
> didn't have a main.conf.  Being happy with this, I didn't ask questions
> and likely incorrectly assumed it was because of what I was setting the
> correct bits in the advertising data.
> 
> After updating to 5.32, my devices are defaulting to dual mode, according
> to 'btmgmt info'.
> 
> After creating a main.conf and setting ControllerMode = le, my 5.32
> devices are now seen as LE only.  This was probably the cause of my issue.
> Would like to know how I was able to get away without a main.conf before
> though.

by default dual-mode controllers should have always set up as BR/EDR and LE enabled. Only after we introduced the ControllerMode main.conf option it was possible to create a LE only mode when running bluetoothd.

The kernel has supported LE only since a long time, but until lately it was manual setup via btmgmt and we only ever used it for testing purposes.

Regards

Marcel