On Tue, Mar 20, 2012 at 2:21 PM, Mike <puffy.taco@xxxxxxxxx> wrote:
> On Tue, Mar 20, 2012 at 1:39 PM, Mike <puffy.taco@xxxxxxxxx> wrote:
>> On Tue, Mar 20, 2012 at 1:27 PM, Mike <puffy.taco@xxxxxxxxx> wrote:
>>> On Tue, Mar 20, 2012 at 12:35 PM, Vinicius Costa Gomes
>>> <vinicius.gomes@xxxxxxxxxxxxx> wrote:
>>>> Hi,
>>>>
>>>> On 20:04 Mon 19 Mar, Johan Hedberg wrote:
>>>>> Hi Mike,
>>>>>
>>>>> On Mon, Mar 19, 2012, Mike wrote:
>>>>> > I notice a change in commit d2920be715974795b51f9cc3279947104da3647b
>>>>> > [1] that changes the "reverse" variable for an SDP query:
>>>>> >
>>>>> > - device_browse_sdp(device, NULL, NULL, NULL, TRUE);
>>>>> > + if (device_is_bredr(device))
>>>>> > + device_browse_sdp(device, NULL, NULL, NULL, FALSE);
>>>>> > + else
>>>>> > + device_browse_primary(device, NULL, NULL, FALSE);
>>>>> >
>>>>> > You can see the original had reverse as TRUE, but the patch may have
>>>>> > inadvertently changed it to FALSE..kernel.org/majordomo-info.html
>>>>>
>>>>> That looks like a definitive bug. Good that you caught it. Vinicius
>>>>> (author of the commit) care to comment?
>>>>
>>>> It was changed to false by mistake, a patch to fix it should be arriving
>>>> on the mailing list in a few moments.
>>>>
>>>> The comment on src/device.c around line 1683 gives some hints on what
>>>> my mistake may have caused: it could be that the device while connected
>>>> "hides" some items from its service record. So with reverse set to
>>>> false, some records that are present are being removed by mistake.
>>>
>>> I'm not sure that's the case here. I added some code to print out the
>>> contents of "device->uuids" at the beginning of update_services
>>> (src/device.c), and here is what I got:
>>>
>>> UUID 0000110d-0000-1000-8000-00805f9b34fb
>>> UUID 0000111f-0000-1000-8000-00805f9b34fb
>>> UUID 0000110d-0000-1000-8000-00805f9b34fb
>>> UUID 0000111f-0000-1000-8000-00805f9b34fb
>>>
>>> A little curious why the UUIDs are duplicated, but besides that, we
>>> can see that my phone already attempted to connect _before_ it was
>>> paired, because it thought it was paired already (pairing deleted on
>>> the BlueZ side only). The UUIDs were added then before SDP could be
>>> done.
>>>
>>> This has me suspecting these lines of code in update_services:
>>>
>>> l = g_slist_find_custom(device->uuids, profile_uuid,
>>> (GCompareFunc) strcmp);
>>> if (!l)
>>> req->profiles_added =
>>> g_slist_append(req->profiles_added,
>>> profile_uuid);
>>> else {
>>> req->profiles_removed =
>>> g_slist_remove(req->profiles_removed,
>>> l->data);
>>> g_free(profile_uuid);
>>> }
>>>
>>> It appears that if a UUID already existed when you did the SDP browse,
>>> it is removed? Why would that be?
>>
>> Ah, I read that wrong. The UUID is removed from the list of profiles
>> to be removed! So that's sane, but I guess the problem is that
>> somehow we have the UUIDs in there twice, which makes this code fail.
>
> Argh. I guess update_services was being called twice, so the UUIDS
> aren't duplicated. I'm still tracing what the real issue is then.
Alright, now I think I understand what's going on. The avdtp.c code
adds ADVANCED_AUDIO_UUID to the UUID list if the device does not
exist. The problem is that ADVANCED_AUDIO_UUID, according to the
assigned numbers document, is only allowed as a profile class. The
code in update_services is checking for service classes, and finds
0x110a (audio source) rather than 0x110d (advanced audio). So, the
real problem in my case is that ADVANCED_AUDIO_UUID is being used as a
service class when it should not. Below is the SDP record from my
phone for the Audio Source:
Service Name: Audio Source
Service Description: Audio Source
Service Provider: /a/mobile/system/cl.gif
Service RecHandle: 0x1000d
Service Class ID List:
"Audio Source" (0x110a)
Protocol Descriptor List:
"L2CAP" (0x0100)
PSM: 25
"AVDTP" (0x0019)
uint16: 0x100
Language Base Attr List:
code_ISO639: 0x656e
encoding: 0x6a
base_offset: 0x100
code_ISO639: 0x6672
encoding: 0x6a
base_offset: 0xc800
code_ISO639: 0x6573
encoding: 0x6a
base_offset: 0xc803
code_ISO639: 0x7074
encoding: 0x6a
base_offset: 0xc806
Profile Descriptor List:
"Advanced Audio" (0x110d)
Version: 0x0100
--
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
