Date: Mon, 28 Nov 2005 19:42:26 -0800 From: Maksim Yevmenkin <maksim.yevmenkin@savvis.net> To: faigozhu <faigozhu@fastmail.fm> Cc: freebsd-bluetooth@freebsd.org Subject: Re: Sdpcontrol search timeout in Motorola HS805 headset. Message-ID: <438BCE22.3050901@savvis.net> In-Reply-To: <86ek5019ld.fsf@fastmail.fm> References: <863blgzdz0.fsf@fastmail.fm> <438B7FB0.5030704@savvis.net> <86psok1jl6.fsf@fastmail.fm> <438B9E3E.5020905@savvis.net> <86ek5019ld.fsf@fastmail.fm>
next in thread | previous in thread | raw e-mail | index | archive | help
[...] >> 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> <Encryption> <Slot offset> > <Timing accuracy> <Switch> <Hold mode> <Sniff mode> <RSSI> > <Channel quality> <SCO link> <HV2 packets> <HV3 packets> > <u-law log> <A-law log> <CVSD> <Power control> > <Transparent SCO data> > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?438BCE22.3050901>