From owner-freebsd-bluetooth@FreeBSD.ORG Thu Dec 9 18:45:15 2004 Return-Path: Delivered-To: freebsd-bluetooth@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 796D416A4CE for ; Thu, 9 Dec 2004 18:45:15 +0000 (GMT) Received: from mailgate1b.savvis.net (mailgate1b.savvis.net [216.91.182.6]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1A0D243D2D for ; Thu, 9 Dec 2004 18:45:15 +0000 (GMT) (envelope-from Maksim.Yevmenkin@savvis.net) Received: from out002.email.savvis.net (out002.apptix.savvis.net [216.91.32.45])iB9Ij3sH009655; Thu, 9 Dec 2004 12:45:03 -0600 Received: from s228130hz1ew03.apptix-01.savvis.net ([10.146.4.28]) by out002.email.savvis.net with Microsoft SMTPSVC(6.0.3790.211); Thu, 9 Dec 2004 12:44:55 -0600 Received: from [10.254.186.111] ([66.35.239.94]) by s228130hz1ew03.apptix-01.savvis.net with Microsoft SMTPSVC(6.0.3790.211); Thu, 9 Dec 2004 12:44:45 -0600 Message-ID: <41B89D1C.2050601@savvis.net> Date: Thu, 09 Dec 2004 10:44:44 -0800 From: Maksim Yevmenkin User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.2) Gecko/20040822 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tuc at Beach House References: <200412091831.iB9IVIDY016237@himinbjorg.tucs-beachin-obx-house.com> In-Reply-To: <200412091831.iB9IVIDY016237@himinbjorg.tucs-beachin-obx-house.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Dec 2004 18:44:45.0306 (UTC) FILETIME=[2702BDA0:01C4DE1F] X-ECS-MailScanner: No virus is found cc: freebsd-bluetooth@freebsd.org cc: Tuc at Beach House Subject: Re: sdpcontrol issues (LONG) X-BeenThere: freebsd-bluetooth@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Using Bluetooth in FreeBSD environments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Dec 2004 18:45:15 -0000 Tuc at Beach House wrote: >>no problem. but,i think, you did not comment out original code, i.e you >>just added >> >>SDP_ATTR_RANGE( 0, 1 ), >>SDP_ATTR_RANGE( 3, 4 ), >>SDP_ATTR_RANGE( 8, 9 ), >> >>on top. you *need* to *comment out* (or remove) the following part >> >> SDP_ATTR_RANGE( SDP_ATTR_SERVICE_RECORD_HANDLE, >> SDP_ATTR_SERVICE_RECORD_HANDLE), >> SDP_ATTR_RANGE( SDP_ATTR_SERVICE_CLASS_ID_LIST, >> SDP_ATTR_SERVICE_CLASS_ID_LIST), >> SDP_ATTR_RANGE( SDP_ATTR_PROTOCOL_DESCRIPTOR_LIST, >> SDP_ATTR_PROTOCOL_DESCRIPTOR_LIST), >> SDP_ATTR_RANGE( SDP_ATTR_BLUETOOTH_PROFILE_DESCRIPTOR_LIST, >> SDP_ATTR_BLUETOOTH_PROFILE_DESCRIPTOR_LIST) >> > > I *THOUGHT* I did...... I didn't. :-/ > >>i.e. sdpcontrol(8) still sends attribute id ranges that consist of only >>one attribute - the problem still there. i want to see something like >> >>< ACL data: handle 0x002a flags 0x02 dlen 56 >> L2CAP(d): cid 0x40 len 52 [psm 1] >> SDP SSA Req: tid 0x0 len 0x2f >> pat uuid-16 0x1105 (OBEXObjPush) >> max 0xffff >> aid(s) 0x0000 - 0x0001 0x0003 - 0x0004 0x0008 - 0x0009 >> cont 00 >> > > Do you see it here? yep, thanks. thats it. here is the response to your 'search opush' command. 1102617014.728752 > ACL data: handle 0x0029 flags 0x02 dlen 56 L2CAP(d): cid 0x5c len 52 [psm 1] SDP SSA Rsp: tid 0x0 len 0x2f cnt 0x2c srv rec #0 aid 0x0000 (SrvRecHndl) uint 0x10001 aid 0x0001 (SrvClassIDList) < uuid-16 0x1105 (OBEXObjPush) > aid 0x0004 (ProtocolDescList) < < uuid-16 0x0100 (L2CAP) > < uuid-16 0x0003 (RFCOMM) uint 0x1 > < uuid-16 0x0008 (OBEX) > > cont 00 i noticed that you also did 'browse' but you got nothing, right? that's normal, as long as you are not getting any errors from sdpcontrol(8). i will commit a bit different patch (to libsdp(3)) that will work around this problem. for now please undo all the changes to the sdpcontrol(8). i will send you libsdp(3) patch to apply in separate email. sigh.. some smartphones are not so smart after all :( > One thing that has happened is after doing some of these I've had > random full lockups of the Treo. i'd say this has nothing to do with this. all we are doing is opening bluetooth connection and sending some data. this should not cause any lockups on any side. if it does then i'd say its treo's fault. thanks, max