Problems with incoming connection request on Nexus 4

DISCUSSION Florian Grandel 5 participants 12 messages Jul 29, 2015 – Aug 5, 2015 Bluetooth drivers

Share & tools

Florian Grandel

author

2015-07-29 02:10 UTC #0 lore raw

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

Marcel Holtmann

maintainer

2015-07-29 13:51 UTC #1 lore raw

Hi Florian,

Quoted 38 lines

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

Quoted 7 lines

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

Florian Grandel

author

2015-07-30 12:21 UTC #2 lore raw

Hi Marcel,

Quoted 9 lines

Quoted 7 lines
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)

Quoted 1 line

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)

Quoted 1 line

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.

Quoted 1 line

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

Marcel Holtmann

maintainer

2015-07-30 12:25 UTC #3 lore raw

Hi Florian,

Quoted 26 lines

Quoted 9 lines
Quoted 7 lines
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)
Quoted 1 line
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)

Quoted 5 lines

Quoted 1 line
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

Florian Grandel

author

2015-07-30 13:11 UTC #4 lore raw

Hi Marcel and Szymon,

Quoted 29 lines · Marcel Holtmann

Hi Florian,
Quoted 27 lines
Quoted 9 lines
Quoted 7 lines
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)
Quoted 1 line
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)
Quoted 1 line
HCI Event: Command Complete (0x0e) plen 4 [hci0] 4.402277

Quoted 8 lines

Quoted 4 lines
      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

Quoted 1 line

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)

Quoted 1 line

HCI Event: Command Status (0x0f) plen 4 [hci0] 9.148347

      Accept Connection Request (0x01|0x0009) ncmd 1
        Status: Success (0x00)

Quoted 1 line

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)

Quoted 1 line

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)

Quoted 1 line

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

Quoted 1 line

HCI Event: Command Status (0x0f) plen 4 [hci0] 9.418910

      Read Remote Supported Features (0x01|0x001b) ncmd 1
        Status: Success (0x00)

Quoted 1 line

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

Quoted 1 line

HCI Event: Command Status (0x0f) plen 4 [hci0] 9.424373

      Read Remote Extended Features (0x01|0x001c) ncmd 1
        Status: Success (0x00)

Quoted 1 line

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)

Quoted 1 line

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

Quoted 1 line

HCI Event: Command Status (0x0f) plen 4 [hci0] 9.428554

      Remote Name Request (0x01|0x0019) ncmd 1
        Status: Success (0x00)

Quoted 1 line

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

Quoted 1 line

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

Quoted 1 line

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

Quoted 1 line

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)

Quoted 1 line

HCI Event: Number of Completed Packets (0x13) plen 5 [hci0] 9.559304

Num handles: 1
Handle: 4
Count: 1

Quoted 1 line

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)

Quoted 1 line

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)

Quoted 1 line

HCI Event: Number of Completed Packets (0x13) plen 5 [hci0] 9.564309

Num handles: 1
Handle: 4
Count: 1

Quoted 1 line

HCI Event: Number of Completed Packets (0x13) plen 5 [hci0] 9.586802

Num handles: 1
Handle: 4
Count: 1

Quoted 1 line

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

Quoted 1 line

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

Quoted 1 line

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)

Quoted 1 line

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

Quoted 1 line

HCI Event: Number of Completed Packets (0x13) plen 5 [hci0] 9.686787

Num handles: 1
Handle: 4
Count: 1

Quoted 1 line

HCI Event: Number of Completed Packets (0x13) plen 5 [hci0] 9.689687

Num handles: 1
Handle: 4
Count: 1

Quoted 1 line

HCI Event: Number of Completed Packets (0x13) plen 5 [hci0] 9.690602

Num handles: 1
Handle: 4
Count: 1

Quoted 1 line

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

Quoted 1 line

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

Quoted 1 line

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)

Quoted 1 line

HCI Event: Command Status (0x0f) plen 4 [hci0] 43.628249

      Disconnect (0x01|0x0006) ncmd 1
        Status: Success (0x00)

Quoted 1 line

HCI Event: Read Clock Offset Complete (0x1c) plen 5 [hci0] 43.637192

        Status: Connection Terminated By Local Host (0x16)
        Handle: 4
        Clock offset: 0x0000

Quoted 1 line

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

Marcel Holtmann

maintainer

2015-07-30 16:00 UTC #5 lore raw

Hi Florian,

Quoted 40 lines

Quoted 27 lines
Quoted 27 lines
Quoted 9 lines
Quoted 7 lines
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)
Quoted 1 line
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)
Quoted 1 line
HCI Event: Command Complete (0x0e) plen 4 [hci0] 4.402277
Quoted 8 lines
Quoted 4 lines
     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
Quoted 1 line
HCI Event: Connect Request (0x04) plen 10 [hci0] 9.147279

Quoted 9 lines

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

Adam Moore

2015-07-30 16:22 UTC #6 lore raw

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.

Quoted 87 lines · On Thu, Jul 30, 2015 at 09:10 Marcel Holtmann <[email protected]> wrote:

Hi Florian,
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
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.
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
- the device is stuck in the CONNECT READY state and never reaches
the CONNECTED state
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Any ideas how I could analyze/solve that problem? I'm stuck on this
for many hours already...
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
Quoted 2 lines
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
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
@ Advertising Added: 1
< HCI Command: LE Set Advertising Para.. (0x08|0x0006) plen 15 [hci0]
4.398493
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
       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)
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
HCI Event: Command Complete (0x0e) plen 4 [hci0]
4.401392
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
     LE Set Advertising Parameters (0x08|0x0006) ncmd 1
       Status: Success (0x00)
< HCI Command: LE Set Advertise Enable (0x08|0x000a) plen 1 [hci0]
4.401484
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
       Advertising: Enabled (0x01)
Quoted 1 line
HCI Event: Command Complete (0x0e) plen 4 [hci0]
4.402277
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
     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.
Quoted 2 lines
Quoted 2 lines
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.
Quoted 2 lines
Quoted 2 lines
If it would connect, then you would see an LE Connect Complete event
indicated that the connection has been established.
Quoted 4 lines
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
Quoted 1 line
Quoted 1 line
HCI Event: Connect Request (0x04) plen 10 [hci0]
9.147279
Quoted 9 lines
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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Lukasz Rymanowski

2015-07-31 19:47 UTC #7 lore raw

In reply to Marcel Holtmann

Hi Florian,

On Thu, Jul 30, 2015 at 6:00 PM, Marcel Holtmann <[email protected]> wrot= e:

Quoted 6 lines

Hi Florian,
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
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.

Quoted 1 line

Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
- the device is stuck in the CONNECT READY state and never reaches =

the CONNECTED state

Quoted 3 lines

Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Any ideas how I could analyze/solve that problem? I'm stuck on this=

for many hours already...

Quoted 4 lines

Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
Quoted 2 lines
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

Quoted 2 lines

Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
@ Advertising Added: 1
< HCI Command: LE Set Advertising Para.. (0x08|0x0006) plen 15 [hci0=

] 4.398493

Quoted 8 lines

       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)

Quoted 1 line

Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
HCI Event: Command Complete (0x0e) plen 4 [hci0]=

4.401392

Quoted 3 lines

Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
     LE Set Advertising Parameters (0x08|0x0006) ncmd 1
       Status: Success (0x00)
< HCI Command: LE Set Advertise Enable (0x08|0x000a) plen 1 [hci0=

] 4.401484

Quoted 2 lines

Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
       Advertising: Enabled (0x01)
Quoted 1 line
HCI Event: Command Complete (0x0e) plen 4 [hci0]=

4.402277

Quoted 4 lines

Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
     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.

Quoted 2 lines

Quoted 2 lines
Quoted 2 lines
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.

Quoted 2 lines

Quoted 2 lines
Quoted 2 lines
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.

Quoted 3 lines

Quoted 3 lines
Sorry, I left out the actual connection part the first time. Here it is=

Quoted 2 lines

Quoted 2 lines
=3D New Index: 10:68:3F:56:AD:35 (BR/EDR,UNKNOWN,hci0) [hci0=

] 0.248759

Quoted 1 line

Quoted 1 line
Quoted 1 line
HCI Event: Connect Request (0x04) plen 10 [hci0] =

9.147279

Quoted 11 lines

Quoted 9 lines
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.

Quoted 2 lines

But it is hilarious that your phone stack sees an LE advertising and then=

connects to you over BR/EDR.

Quoted 5 lines

Regards
Marcel

=C5=81ukasz

Quoted 3 lines

--
To unsubscribe from this list: send the line "unsubscribe linux-bluetooth=

" in

Quoted 2 lines

the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Adam Moore

2015-07-31 22:41 UTC #8 lore raw

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.

Quoted 107 lines · On 7/31/15, 12:47 PM, "[email protected] on behalf of…

Hi Florian,
Quoted 49 lines · Marcel Holtmann
Hi Florian,
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
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.
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
- the device is stuck in the CONNECT READY state and never
reaches the CONNECTED state
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Any ideas how I could analyze/solve that problem? I'm stuck on
this for many hours already...
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
Quoted 2 lines
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
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
@ Advertising Added: 1
< HCI Command: LE Set Advertising Para.. (0x08|0x0006) plen 15
[hci0] 4.398493
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
       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)
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
HCI Event: Command Complete (0x0e) plen 4
[hci0] 4.401392
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
     LE Set Advertising Parameters (0x08|0x0006) ncmd 1
       Status: Success (0x00)
< HCI Command: LE Set Advertise Enable (0x08|0x000a) plen 1
[hci0] 4.401484
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
       Advertising: Enabled (0x01)
Quoted 1 line
HCI Event: Command Complete (0x0e) plen 4
[hci0] 4.402277
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
     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.
Quoted 1 line
Quoted 1 line
Quoted 6 lines
Quoted 1 line
Quoted 1 line
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.
Quoted 2 lines
Quoted 2 lines
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.
Quoted 24 lines
Quoted 3 lines
Sorry, I left out the actual connection part the first time. Here it
is:
Quoted 2 lines
=3D New Index: 10:68:3F:56:AD:35 (BR/EDR,UNKNOWN,hci0)
[hci0] 0.248759
Quoted 1 line
Quoted 1 line
HCI Event: Connect Request (0x04) plen 10
[hci0] 9.147279
Quoted 9 lines
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.
Quoted 7 lines
But it is hilarious that your phone stack sees an LE advertising and then connects to you over BR/EDR.
Regards
Marcel
=A3ukasz
Quoted 6 lines
--
To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Quoted 5 lines

--
To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
the body of a message to [email protected]
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.

Florian Grandel

author

2015-08-01 18:54 UTC #9 lore raw

Hi Adam and Lukasz,

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

Florian

Quoted 138 lines · 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.
Quoted 107 lines · On 7/31/15, 12:47 PM, "[email protected] on behalf of…
Hi Florian,
Quoted 49 lines · Marcel Holtmann
Hi Florian,
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
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.
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
- the device is stuck in the CONNECT READY state and never
reaches the CONNECTED state
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Any ideas how I could analyze/solve that problem? I'm stuck on
this for many hours already...
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
Quoted 2 lines
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
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
@ Advertising Added: 1
< HCI Command: LE Set Advertising Para.. (0x08|0x0006) plen 15
[hci0] 4.398493
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
        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)
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
HCI Event: Command Complete (0x0e) plen 4
[hci0] 4.401392
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
      LE Set Advertising Parameters (0x08|0x0006) ncmd 1
        Status: Success (0x00)
< HCI Command: LE Set Advertise Enable (0x08|0x000a) plen 1
[hci0] 4.401484
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
        Advertising: Enabled (0x01)
Quoted 1 line
HCI Event: Command Complete (0x0e) plen 4
[hci0] 4.402277
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
      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.
Quoted 1 line
Quoted 1 line
Quoted 6 lines
Quoted 1 line
Quoted 1 line
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.
Quoted 2 lines
Quoted 2 lines
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.
Quoted 24 lines
Quoted 3 lines
Sorry, I left out the actual connection part the first time. Here it
is:
Quoted 2 lines
= New Index: 10:68:3F:56:AD:35 (BR/EDR,UNKNOWN,hci0)
[hci0] 0.248759
Quoted 1 line
Quoted 1 line
HCI Event: Connect Request (0x04) plen 10
[hci0] 9.147279
Quoted 9 lines
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.
Quoted 7 lines
But it is hilarious that your phone stack sees an LE advertising and then connects to you over BR/EDR.
Regards
Marcel
Łukasz
Quoted 6 lines
--
To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 5 lines
--
To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
the body of a message to [email protected]
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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Adam Moore

2015-08-05 00:07 UTC #10 lore raw

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.

Quoted 159 lines · Florian Grandel

Hi Adam and Lukasz,
thanks for your feedback and insight. I'll let you know when I make progress.
Florian
Quoted 150 lines · 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, "[email protected] on behalf of
Lukasz Rymanowski" <[email protected] on behalf of
Quoted 109 lines · [email protected]> wrote:
Hi Florian,
Quoted 49 lines · Marcel Holtmann
Hi Florian,
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
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.
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
- the device is stuck in the CONNECT READY state and never
reaches the CONNECTED state
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Any ideas how I could analyze/solve that problem? I'm stuck on
this for many hours already...
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
Quoted 2 lines
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
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
@ Advertising Added: 1
< HCI Command: LE Set Advertising Para.. (0x08|0x0006) plen 15
[hci0] 4.398493
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
        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)
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
HCI Event: Command Complete (0x0e) plen 4
[hci0] 4.401392
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
      LE Set Advertising Parameters (0x08|0x0006) ncmd 1
        Status: Success (0x00)
< HCI Command: LE Set Advertise Enable (0x08|0x000a) plen 1
[hci0] 4.401484
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
        Advertising: Enabled (0x01)
Quoted 1 line
HCI Event: Command Complete (0x0e) plen 4
[hci0] 4.402277
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
      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.
Quoted 1 line
Quoted 1 line
Quoted 7 lines
Quoted 1 line
Quoted 1 line
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.
Quoted 2 lines
Quoted 2 lines
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.
Quoted 25 lines
Quoted 3 lines
Sorry, I left out the actual connection part the first time. Here it
is:
Quoted 2 lines
= New Index: 10:68:3F:56:AD:35 (BR/EDR,UNKNOWN,hci0)
[hci0] 0.248759
Quoted 1 line
Quoted 1 line
HCI Event: Connect Request (0x04) plen 10
[hci0] 9.147279
Quoted 9 lines
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.
Quoted 7 lines
But it is hilarious that your phone stack sees an LE advertising and then connects to you over BR/EDR.
Regards
Marcel
Łukasz
Quoted 6 lines
--
To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 5 lines
--
To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
the body of a message to [email protected]
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 [email protected]
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.

Marcel Holtmann

maintainer

2015-08-05 01:32 UTC #11 lore raw

Hi Adam,

please refrain from top posting on this mailing list.

Quoted 5 lines

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.

Quoted 7 lines

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