From owner-freebsd-bluetooth@FreeBSD.ORG Sat Nov 8 01:03:12 2008 Return-Path: Delivered-To: freebsd-bluetooth@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2D0C9106567D for ; Sat, 8 Nov 2008 01:03:12 +0000 (UTC) (envelope-from mad@madpilot.net) Received: from megatron.madpilot.net (megatron.madpilot.net [88.149.173.206]) by mx1.freebsd.org (Postfix) with ESMTP id BE8988FC12 for ; Sat, 8 Nov 2008 01:03:11 +0000 (UTC) (envelope-from mad@madpilot.net) Received: from localhost (localhost [127.0.0.1]) by megatron.madpilot.net (Postfix) with ESMTP id 29CF9130C08; Sat, 8 Nov 2008 02:03:10 +0100 (CET) X-Virus-Scanned: amavisd-new at madpilot.net Received: from megatron.madpilot.net ([127.0.0.1]) by localhost (megatron.madpilot.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rWzWl5QTHyoo; Sat, 8 Nov 2008 02:03:07 +0100 (CET) Received: from wedge.madpilot.net (wedge.madpilot.net [172.24.42.11]) by megatron.madpilot.net (Postfix) with ESMTP; Sat, 8 Nov 2008 02:03:07 +0100 (CET) Message-ID: <4914E54B.4060206@madpilot.net> Date: Sat, 08 Nov 2008 02:03:07 +0100 From: Guido Falsi User-Agent: Thunderbird 2.0.0.17 (X11/20080927) MIME-Version: 1.0 To: Iain Hibbert References: <20081104111947.GB62907@megatron.madpilot.net> <1225799105.807983.1164.nullmailer@galant.ukfsn.org> <20081104135107.GA64776@megatron.madpilot.net> <1225821264.107584.759.nullmailer@galant.ukfsn.org> <4910B6E6.7070206@madpilot.net> <4910CA97.6030708@madpilot.net> <1226091521.039371.399.nullmailer@galant.ukfsn.org> <4914B113.60303@madpilot.net> <1226097099.328979.788.nullmailer@galant.ukfsn.org> In-Reply-To: <1226097099.328979.788.nullmailer@galant.ukfsn.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-bluetooth@freebsd.org Subject: Re: RFComm behaviour with nokia mobiles X-BeenThere: freebsd-bluetooth@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Using Bluetooth in FreeBSD environments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Nov 2008 01:03:12 -0000 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[] = { SDP_ATTR_RANGE( SDP_ATTR_PRIMARY_LANGUAGE_BASE_ID+SDP_ATTR_SERVICE_NAME_OFFSET, SDP_ATTR_PRIMARY_LANGUAGE_BASE_ID+SDP_ATTR_SERVICE_NAME_OFFSET), SDP_ATTR_RANGE( SDP_ATTR_PROTOCOL_DESCRIPTOR_LIST, SDP_ATTR_PROTOCOL_DESCRIPTOR_LIST), }; 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