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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
