Return-Path: MIME-Version: 1.0 References: <55B83614.8090702@gmail.com> <55BA16BA.5060302@gmail.com> <55BA2290.8090308@gmail.com> <2C03C1D8-0784-4DA4-93AF-FC8A1C874681@holtmann.org> In-Reply-To: <2C03C1D8-0784-4DA4-93AF-FC8A1C874681@holtmann.org> From: Adam Moore Date: Thu, 30 Jul 2015 16:22:50 +0000 Message-ID: Subject: Re: Problems with incoming connection request on Nexus 4 To: Marcel Holtmann , Florian Grandel Cc: Szymon Janc , BlueZ development Content-Type: multipart/alternative; boundary=001a113a5656ea08a7051c1a1dfa List-ID: --001a113a5656ea08a7051c1a1dfa Content-Type: text/plain; charset=UTF-8 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 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 > --001a113a5656ea08a7051c1a1dfa Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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 flag= s. Maybe it just needs to be set.
On Thu, Ju= l 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 (= =3Dconnect_cb) only gets called when the request times out.
>>>>> - the device is stuck in the CONNECT READY state and n= ever reaches the CONNECTED state
>>>>>
>>>>>
>>>>> Any ideas how I could analyze/solve that problem? I= 9;m stuck on this for many hours already...
>>>>
>>>> what does btmon actually tell you about what is going on w= ith HCI.
>>>
>>> =3D New Index: 10:68:3F:56:AD:35 (BR/EDR,UNKNOWN,hci0)=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [hci0] 0.629837
>>> @ Advertising Added: 1
>>> < HCI Command: LE Set Advertising Para.. (0x08|0x0006) plen= 15=C2=A0 [hci0] 4.398493
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Min advertising interval: 1280.000 = msec (0x0800)
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Max advertising interval: 1280.000 = msec (0x0800)
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Type: Connectable undirected - ADV_= IND (0x00)
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Own address type: Public (0x00)
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Direct address type: Public (0x00)<= br> >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Direct address: 00:00:00:00:00:00 (= OUI 00-00-00)
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Channel map: 37, 38, 39 (0x07)
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filter policy: Allow Scan Request f= rom Any, Allow Connect Request from Any (0x00)
>>>> HCI Event: Command Complete (0x0e) plen 4=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[hci0] 4.401392<= br> >>>=C2=A0 =C2=A0 =C2=A0 LE Set Advertising Parameters (0x08|0x0006= ) ncmd 1
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Status: Success (0x00)
>>> < HCI Command: LE Set Advertise Enable (0x08|0x000a) plen 1= =C2=A0 =C2=A0 =C2=A0[hci0] 4.401484
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Advertising: Enabled (0x01)
>>>> HCI Event: Command Complete (0x0e) plen 4=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[hci0] 4.402277<= br> >>>=C2=A0 =C2=A0 =C2=A0 LE Set Advertise Enable (0x08|0x000a) ncmd= 1
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 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.<= br> >>
>> 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 N= exus 4 to connect.
>>
>> If it would connect, then you would see an LE Connect Complete eve= nt indicated that the connection has been established.
>
> Sorry, I left out the actual connection part the first time. Here it i= s:
>
> =3D New Index: 10:68:3F:56:AD:35 (BR/EDR,UNKNOWN,hci0)=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 [hci0] 0.248759
> > HCI Event: Connect Request (0x04) plen 10=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[hci0] 9.147279
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Address: 94:01:C2:AB:46:05 (OUI 94-01-C2) >=C2=A0 =C2=A0 =C2=A0 =C2=A0 Class: 0x5a020c
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Major class: Phone (cellular, cordle= ss, payphone, modem)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Minor class: Smart phone
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Networking (LAN, Ad hoc)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Capturing (Scanner, Microphone)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Object Transfer (v-Inbox, v-Folder)<= br> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Telephony (Cordless telephony, Modem= , Headset)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Link type: ACL (0x01)

this is a BR/EDR connection. So it seems even while it sees you advertise o= n LE, it then connects using BR/EDR. Since Bluetooth 4.0 did not allow BR/E= DR 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 c= onnects to you over BR/EDR.

Regards

Marcel

--
To unsubscribe from this list: send the line "unsubscribe linux-blueto= oth" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at=C2=A0 http://vger.kernel.org/majord= omo-info.html
--001a113a5656ea08a7051c1a1dfa--