RFComm behaviour with nokia mobiles
mad at madpilot.net
Fri Nov 7 17:03:12 PST 2008
Iain Hibbert wrote:
> On Fri, 7 Nov 2008, Guido Falsi wrote:
>> Iain Hibbert wrote:
>>> The attribute ID list should be in ascending order according to
>>> the specification. This means though that some logic could be
>>> wrong because the protocol descriptor list for any given service
>>> class would likely appear before the service name in the response
>>> attribute list and you would use the wrong channel..
>> Uhm, I did not get this detail in the specification.
> You can find this in the small print of the SDP spec sections
> relating to ServiceSearch and ServiceSearchAttribute requests, in the
> AttributeIDList box.
> I guess its so that a server can do a straight pass through search
> without having to loop up and down the list, but I don't know if that
> would work out simpler or not in practice. Obviously the Nokia people
> thought not, as it worked anyway :)
After some reading, some coding and some experimenting I think I found
what is happening.
I have this code(I hope mozilla will not mangle this too much):
uint32_t attrs =
so I define 2 ranges with a single attribute in each. This one defines
the order in which objects are returned.
Since I think code written the way you suggested is cleaner and more
readable I'll just swap the two ranges and have it work the way you said.
I think FreeBSD's sdp is making 2 requests in this case...Or maybe
forcing the order to be the same as the request.
Guido Falsi <mad at madpilot.net>
More information about the freebsd-bluetooth