* Fwd: Inconsistencies with UUIDs in XML service descriptors
[not found] <11f7a7550901090850x4c276806v6c3c4bfad804986f@mail.gmail.com>
@ 2009-01-09 16:52 ` Daniele Benucci
2009-01-10 12:02 ` Daniele Benucci
0 siblings, 1 reply; 6+ messages in thread
From: Daniele Benucci @ 2009-01-09 16:52 UTC (permalink / raw)
To: linux-bluetooth
[-- Attachment #1: Type: text/plain, Size: 981 bytes --]
I've noticed a strange behaviour in the last versions of Bluez (at
least >= 4.19) when retrieving services via the DBus method in
org.bluez.Device.DiscoverServices:
the XMLs returned by this DBus call have the "value" attribute of
_every_ "uuid" element set to "0x0019", for the records with 16-bit
uuids.
128-bit uuids are not correctly represented too, seeming to be 4-bytes
right-shifted.
When performing service discovery via sdptool with the --xml parameter
the output is correct.
I'm attaching two examples for the two cases
I experienced this in Bluez 4.19 shipped with OpenSuse 11.1, and in
Bluez 4.25 packaged for Ubuntu 8.10 (unofficial) at
http://ppa.launchpad.net/blueman/. This does not happen in Bluez 4.12
shipped with Ubuntu 8.10
I'm posting here this report as I didn't find a Bluez bug tracker and
the bug seems to be distribution-independant
Thanks for your attention
Daniele Benucci
--
Grabel's Law:
2 is not equal to 3 -- not even for large values of 2.
[-- Attachment #2: BluezBug - UUID16.txt --]
[-- Type: text/plain, Size: 2677 bytes --]
XML obtained with sdptool
=========================
<?xml version="1.0" encoding="UTF-8" ?>
<record>
<attribute id="0x0000">
<uint32 value="0x00010005" />
</attribute>
<attribute id="0x0001">
<sequence>
<uuid value="0x1105" /> <---- Note here
</sequence>
</attribute>
<attribute id="0x0002">
<uint32 value="0x00000007" />
</attribute>
<attribute id="0x0004">
<sequence>
<sequence>
<uuid value="0x0100" /> <---- Note here
</sequence>
<sequence>
<uuid value="0x0003" /> <---- Note here
<uint8 value="0x09" />
</sequence>
<sequence>
<uuid value="0x0008" /> <---- Note here
</sequence>
</sequence>
</attribute>
<attribute id="0x0005">
<sequence>
<uuid value="0x1002" /> <---- Note here
</sequence>
</attribute>
<attribute id="0x0006">
<sequence>
<uint16 value="0x454e" />
<uint16 value="0x006a" />
<uint16 value="0x0100" />
</sequence>
</attribute>
<attribute id="0x0009">
<sequence>
<sequence>
<uuid value="0x1105" /> <---- Note here
<uint16 value="0x0100" />
</sequence>
</sequence>
</attribute>
<attribute id="0x0100">
<text value="OBEX Object Push" />
</attribute>
<attribute id="0x0303">
<sequence>
<uint8 value="0xff" />
</sequence>
</attribute>
</record>
--------------------------------------------------------------
Same XML obtained with DBus DiscoverServices call
=================================================
<?xml version="1.0" encoding="UTF-8" ?>
<record>
<attribute id="0x0000">
<uint32 value="0x00010005" />
</attribute>
<attribute id="0x0001">
<sequence>
<uuid value="0x0019" /> <---- Note here
</sequence>
</attribute>
<attribute id="0x0002">
<uint32 value="0x00000007" />
</attribute>
<attribute id="0x0004">
<sequence>
<sequence>
<uuid value="0x0019" /> <---- Note here
</sequence>
<sequence>
<uuid value="0x0019" /> <---- Note here
<uint8 value="0x09" />
</sequence>
<sequence>
<uuid value="0x0019" /> <---- Note here
</sequence>
</sequence>
</attribute>
<attribute id="0x0005">
<sequence>
<uuid value="0x0019" /> <---- Note here
</sequence>
</attribute>
<attribute id="0x0006">
<sequence>
<uint16 value="0x454e" />
<uint16 value="0x006a" />
<uint16 value="0x0100" />
</sequence>
</attribute>
<attribute id="0x0009">
<sequence>
<sequence>
<uuid value="0x0019" /> <---- Note here
<uint16 value="0x0100" />
</sequence>
</sequence>
</attribute>
<attribute id="0x0100">
<text value="OBEX Object Push" />
</attribute>
<attribute id="0x0303">
<sequence>
<uint8 value="0xff" />
</sequence>
</attribute>
</record>
[-- Attachment #3: BluezBug - UUID128.txt --]
[-- Type: text/plain, Size: 2624 bytes --]
XML obtained with sdptool
=========================
<?xml version="1.0" encoding="UTF-8" ?>
<record>
<attribute id="0x0000">
<uint32 value="0x00010003" />
</attribute>
<attribute id="0x0001">
<sequence>
<uuid value="00000002-0000-1000-8000-0002ee000002" /> <---- Note here
</sequence>
</attribute>
<attribute id="0x0002">
<uint32 value="0x00000006" />
</attribute>
<attribute id="0x0004">
<sequence>
<sequence>
<uuid value="0x0100" /> <---- Note here
</sequence>
<sequence>
<uuid value="0x0003" /> <---- Note here
<uint8 value="0x0b" />
</sequence>
<sequence>
<uuid value="0x0008" /> <---- Note here
</sequence>
</sequence>
</attribute>
<attribute id="0x0005">
<sequence>
<uuid value="0x1002" /> <---- Note here
</sequence>
</attribute>
<attribute id="0x0006">
<sequence>
<uint16 value="0x454e" />
<uint16 value="0x006a" />
<uint16 value="0x0100" />
</sequence>
</attribute>
<attribute id="0x0009">
<sequence>
<sequence>
<uuid value="00000002-0000-1000-8000-0002ee000002" /> <---- Note here
<uint16 value="0x0100" />
</sequence>
</sequence>
</attribute>
<attribute id="0x0100">
<text value="SyncMLClient" />
</attribute>
</record>
--------------------------------------------------------------
Same XML obtained with DBus DiscoverServices call
=================================================
<?xml version="1.0" encoding="UTF-8" ?>
<record>
<attribute id="0x0000">
<uint32 value="0x00010003" />
</attribute>
<attribute id="0x0001">
<sequence>
<uuid value="1c000000-0000-0002-0000-100080000002" /> <---- Note here
</sequence>
</attribute>
<attribute id="0x0002">
<uint32 value="0x00000006" />
</attribute>
<attribute id="0x0004">
<sequence>
<sequence>
<uuid value="0x0019" /> <---- Note here
</sequence>
<sequence>
<uuid value="0x0019" /> <---- Note here
<uint8 value="0x0b" />
</sequence>
<sequence>
<uuid value="0x0019" /> <---- Note here
</sequence>
</sequence>
</attribute>
<attribute id="0x0005">
<sequence>
<uuid value="0x0019" /> <---- Note here
</sequence>
</attribute>
<attribute id="0x0006">
<sequence>
<uint16 value="0x454e" />
<uint16 value="0x006a" />
<uint16 value="0x0100" />
</sequence>
</attribute>
<attribute id="0x0009">
<sequence>
<sequence>
<uuid value="1c000000-0000-0002-0000-100080000002" /> <---- Note here
<uint16 value="0x0100" />
</sequence>
</sequence>
</attribute>
<attribute id="0x0100">
<text value="SyncMLClient" />
</attribute>
</record>
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: Inconsistencies with UUIDs in XML service descriptors
2009-01-09 16:52 ` Fwd: Inconsistencies with UUIDs in XML service descriptors Daniele Benucci
@ 2009-01-10 12:02 ` Daniele Benucci
2009-01-10 12:41 ` Johan Hedberg
0 siblings, 1 reply; 6+ messages in thread
From: Daniele Benucci @ 2009-01-10 12:02 UTC (permalink / raw)
To: linux-bluetooth
2009/1/9 Daniele Benucci <d.benux@gmail.com>
> I've noticed a strange behaviour in the last versions of Bluez (at
> least >= 4.19) when retrieving services via the DBus method in
> org.bluez.Device.DiscoverServices:
I compiled 4.18 from source and the result of DiscoverServices reports
the correct UUIDs both for 16-bit and 128-bit
Daniele Benucci
--
Grabel's Law:
2 is not equal to 3 -- not even for large values of 2.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Inconsistencies with UUIDs in XML service descriptors
2009-01-10 12:02 ` Daniele Benucci
@ 2009-01-10 12:41 ` Johan Hedberg
2009-01-12 14:18 ` Daniele Benucci
0 siblings, 1 reply; 6+ messages in thread
From: Johan Hedberg @ 2009-01-10 12:41 UTC (permalink / raw)
To: linux-bluetooth
Hi Daniele,
On Sat, Jan 10, 2009, Daniele Benucci wrote:
> 2009/1/9 Daniele Benucci <d.benux@gmail.com>
> > I've noticed a strange behaviour in the last versions of Bluez (at
> > least >= 4.19) when retrieving services via the DBus method in
> > org.bluez.Device.DiscoverServices:
>
> I compiled 4.18 from source and the result of DiscoverServices reports
> the correct UUIDs both for 16-bit and 128-bit
Looking at the difference between 4.18 and 4.19 (git diff 4.18..4.19) at
least the new sdp_copy_record implementation seems like a potential
candidate for the cause of this. Could you perhaps try to use git bisect
to determine the exact patch that causes the bug?
Johan
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Inconsistencies with UUIDs in XML service descriptors
2009-01-10 12:41 ` Johan Hedberg
@ 2009-01-12 14:18 ` Daniele Benucci
2009-01-12 14:32 ` Johan Hedberg
0 siblings, 1 reply; 6+ messages in thread
From: Daniele Benucci @ 2009-01-12 14:18 UTC (permalink / raw)
To: Johan Hedberg; +Cc: linux-bluetooth
2009/1/10 Johan Hedberg <johan.hedberg@nokia.com>:
> Could you perhaps try to use git bisect
> to determine the exact patch that causes the bug?
According to git-bisect commit introducing the bug is
204180c7dc2e20b9b701275a3fefb52707720f54
(Make use of sdp_copy_record.)
Regards
Daniele.
--
Grabel's Law:
2 is not equal to 3 -- not even for large values of 2.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Inconsistencies with UUIDs in XML service descriptors
2009-01-12 14:18 ` Daniele Benucci
@ 2009-01-12 14:32 ` Johan Hedberg
2009-01-12 20:47 ` Luiz Augusto von Dentz
0 siblings, 1 reply; 6+ messages in thread
From: Johan Hedberg @ 2009-01-12 14:32 UTC (permalink / raw)
To: BlueZ development
Hi Daniele,
On Jan 12, 2009, at 15:18, Daniele Benucci wrote:
> 2009/1/10 Johan Hedberg <johan.hedberg@nokia.com>:
>> Could you perhaps try to use git bisect
>> to determine the exact patch that causes the bug?
>
> According to git-bisect commit introducing the bug is
>
> 204180c7dc2e20b9b701275a3fefb52707720f54
>
> (Make use of sdp_copy_record.)
Thanks a lot! This will really help in investigating and fixing the
issue. We'll most likely have it fixed for the next BlueZ release
(Luiz, who authored the sdp_copy_record function, is now looking into
it).
Johan
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2009-01-12 20:47 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <11f7a7550901090850x4c276806v6c3c4bfad804986f@mail.gmail.com>
2009-01-09 16:52 ` Fwd: Inconsistencies with UUIDs in XML service descriptors Daniele Benucci
2009-01-10 12:02 ` Daniele Benucci
2009-01-10 12:41 ` Johan Hedberg
2009-01-12 14:18 ` Daniele Benucci
2009-01-12 14:32 ` Johan Hedberg
2009-01-12 20:47 ` Luiz Augusto von Dentz
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.