* 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox