From owner-freebsd-bluetooth@FreeBSD.ORG Tue Nov 29 03:42:52 2005 Return-Path: X-Original-To: freebsd-bluetooth@freebsd.org 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 B9B7516A41F for ; Tue, 29 Nov 2005 03:42:52 +0000 (GMT) (envelope-from maksim.yevmenkin@savvis.net) Received: from mta13.adelphia.net (mta13.mail.adelphia.net [68.168.78.44]) by mx1.FreeBSD.org (Postfix) with ESMTP id EDA4643D77 for ; Tue, 29 Nov 2005 03:42:35 +0000 (GMT) (envelope-from maksim.yevmenkin@savvis.net) Received: from [192.168.1.254] (really [70.32.199.60]) by mta13.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with ESMTP id <20051129034232.RFLA12926.mta13.adelphia.net@[192.168.1.254]>; Mon, 28 Nov 2005 22:42:32 -0500 Message-ID: <438BCE22.3050901@savvis.net> Date: Mon, 28 Nov 2005 19:42:26 -0800 From: Maksim Yevmenkin User-Agent: Mozilla Thunderbird 0.7.1 (Windows/20040626) X-Accept-Language: en-us, en MIME-Version: 1.0 To: faigozhu References: <863blgzdz0.fsf@fastmail.fm> <438B7FB0.5030704@savvis.net> <86psok1jl6.fsf@fastmail.fm> <438B9E3E.5020905@savvis.net> <86ek5019ld.fsf@fastmail.fm> In-Reply-To: <86ek5019ld.fsf@fastmail.fm> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-bluetooth@freebsd.org Subject: Re: Sdpcontrol search timeout in Motorola HS805 headset. 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: Tue, 29 Nov 2005 03:42:52 -0000 [...] >> thanks. unfortunately, this binary dump did not reveal the problem. >> i'd like you to try the following: >> >> 1) reboot >> >> 2) attach usb bluetooth dongle and start bluetooth stack > > # /etc/rc.bluetooth start ubt0 > BD_ADDR: 00:0a:3a:63:de:86 > Features: 0xff 0xfe 0xd 0x38 0x8 0x8 00 00 > <3-Slot> <5-Slot> > > > > > Max. ACL packet size: 377 bytes > Number of ACL packets: 10 > Max. SCO packet size: 16 bytes > Number of SCO packets: 0 this looks good. number of sco packets == 0 is strange, but its not your problem. i've seen this in other devices. is this a broadcom chip based device? >> 4) as root >> # hccontrol -n ubt0hci create_connection 00:0b:2e:32:65:12 >> >> make sure hccontrol succeeded and created baseband connection. >> it should print connection handle. > > BD_ADDR: 00:0b:2e:32:65:12 > Connection handle: 6 > Encryption mode: Disabled [0] this looks good as well >> 5) wait a few seconds, and run >> % sdpcontrol -a 00:0b:2e:32:65:12 search HSET > > Could not execute command "search". Operation timed out. well, at least it is consistent >> you may try step 5) a couple more times. please wait few seconds >> between each try. > > still timed out. ok >dmesg: [...] > ubt_bulk_in_complete2: ubt0 - Bulk-in xfer failed, IOERROR (13). No new xfer will be submitted! aha! this is your problem. usb bulk transfer failed. that explains why sdpcontrol failed. bluetooth usb device use usb control transfers to send hci command and usb interrupt transfers to receive hci event. bulk usb transfers used to transfer the data. so, in your case, usb control/interrupt transfers with your device work just fine. that explains why you can send commands to the device and get responses back. however, as soon as you try to transfer data (which require usb bulk transfer) the device chokes. that is why you never see sdp response from the headset - it probably never saw the sdp request, because bulk transfer failed and the data were never transmitted over the radio. what is the model of your bluetooth usb dongle? are you using usb hub? what is your usb controller type uhci, ohci or ehci? thanks, max