Re: help with bluetooth

On Tue, 1 Jan 2008, Dieter Baron wrote:
> > is the bluetooth internal? if usb what kind of usb does it have? There
> > have been problems in the past with ehci buses. can you show the dmesg?
>
> dmesg is attached. It's internal, though connected via uhub2 @
> uhci2.
Hm, though it seems ehci is involved somehow (I'm not sure of the
relationship) and there seems some USB trouble in ugensa later..
> # hcidump -x
> HCIDump - HCI packet analyzer ver 1.5
> device: any snap_len: 65540 filter: 0xffffffff
> < HCI Command: Create Connection(0x01|0x0005) plen 13
> 7B 96 5F DC 1A 00 1E FF 00 00 00 00 01
> > HCI Event: Command Status(0x0f) plen 4
> 12 01 05 04
>
> In dmesg I get the following:
>
> ubt0: CommandStatus opcode (001|0005) failed (status=0x12)
Ok, status 0x12 means the command failed with invalid command parameters
(which blatantly shouldn't happen :) and there is no handling for that
as yet**
- 7B 96 5F DC 1A 00 your phone address
- 1E FF packet types (0xff1e)
- 00 page scan rep mode (is ok to be 0)
- 00 page scan mode (is obsolete and should be 0)
- 00 00 clock offset but( is ok to be 0)
- 01 allow role switch
So. things to try
1. "btconfig ubt0 ptype 0x0018" - I don't know why but some devices seem
to require this or something like. It limits the air packets to the
bare minimum that its mandatory to support rather than what the device
claims to support.
2. "btconfig ubt0 -switch" - disable role switching which means that your
computer will insist on being the master of the connection (it should
not make a difference)
3. turn off ehci somehow (in BIOS you can sometimes switch to legacy USB
but you lose USB2.0 speeds)
4. If you do an "btconfig ubt0 inquiry" beforehand and the device is
discovered, the stack remembers the "clock offset" and "page scan rep
mode" settings for 10 minutes and will use them in the command as it
can help building a connection (I don't know what "page scan rep mode"
is exactly but all three settings are fine to be zero)
5. You could try for incoming connections by setting up comms/obexapp and
attempt to send something from the phone to the computer.
iain
** because annoyingly, when this happens, it does not give any hint as to
which CreateConnection failed. It used to be that a callout would kick in
and interrupt the blockage but that was changed unrelatedly and it doesn't
get activated until afterwards now - in your case there was only one
command failure but I am still thinking about how to handle the error case
in a more general fashion since its allowed to have several commands in
the queue.