[Bluez-users] Connection Timeout

[Bluez-users] Connection Timeout

[Stephen Quattlebaum]

I'm a BT newbie having trouble with device timeouts using bluez.  I've
seen this issue posted a few other places but no answers yet.  Some
background:

I just bought a Microsoft BT mouse for a Win XP laptop and decided this
afternoon to take it for a spin on my Linux box.

I've got kernel 2.6.8 (what gentoo calls 2.6.8.1-ck9; don't know where
the .1 comes from but the ck9 refers to a set of desktop performance
tuning patches they apply).

I applied patch-2.6.9-mh2 from http://www.bluez.org/patches.html and
rebuilt my kernel and modules.

The mouse came with a little USB dongle that has the following info on
the backside:

"Wireless Transceiver for Bluetooth 2.0"
Model: 1003
IC: 3048A-1003

usbview shows the dongle with the name "Wireless Radio for Bluetooth",
and its name is in red, which I've been led to believe means that no
drivers have attached themselves to the device.  I don't know if that's
important here or not.  I'd paste in the usbview output but usbview
appears to not support whatever flavor of cut-and-paste gnome uses.
I'll pull out any info someone asks me for (it's a big listing).  Here's
the first several lines:

Manufacturer: Microsoft
Serial Number: 0050F2E8E590
Speed: 12Mb/s (full)
USB Version: 1.10
Device Class: e0(unk.)
Device Subclass: 01
Device Protocol: 01
Maximum Default Endpoint Size: 64
Number of Configurations: 1
Vendor Id: 045e
Product Id: 009c
Revision Number: 1.00


When I plug in the dongle, the mouse just starts working without me
having to do anything at all (though some of the buttons don't work,
even the scrollwheel, which is working on another USB mouse attached to
this system).  However, that's where the good times end.

Here are the results of various commands:

athene bluetooth # hciconfig
hci0:   Type: USB
        BD Address: 00:00:00:00:00:00 ACL MTU: 0:0  SCO MTU: 0:0
        DOWN
        RX bytes:0 acl:0 sco:0 events:0 errors:0
        TX bytes:0 acl:0 sco:0 commands:0 errors:0


athene bluetooth # hcitool scan
Device is not available: Success

athene bluetooth # hciconfig hci0 up
Can't init device hci0. Connection timed out(110)


I saw somewhere that I should try hcidump -x while doing that last one,
and here's what I get.

athene root # hcidump -x
HCIDump - HCI packet analyzer ver 1.9
device: hci0 snap_len: 1028 filter: 0xffffffff
< HCI Command: Read Local Supported Features (0x04|0x0003) plen 0
< HCI Command: Read Local Supported Features (0x04|0x0003) plen 0
...

What you see there is the result of trying "hciconfig hci0 up" twice.  I
get a new "< HCI Command" line for each time I try.  I'm _guessing_ that
the < means "outgoing", and that maybe the problem is that the dongle is
never responding to that particular request like it should?

All through this, the mouse actually _works_, but it doesn't show up in
response to "hcitool dev" (nothing does) and I can't probe devices, so I
can't make a connection to my Sony Ericsson T610 (or, presumably, any
other devices).

I saw a suggestion to start hcid on the list, so I did, but it doesn't
appear to affect anything.  I tried "hcid -n" so I could see what it was
doing and got this:

athene bluetooth # hcid -n
hcid[13197]: Bluetooth HCI daemon
hcid[13198]: Can't init device hci0. Connection timed out(110)

hcid _does_ notice when I remove and replace the dongle, but it still
cant ever connect:

hcid[13197]: HCI dev 0 unregistered
hcid[13197]: HCI dev 0 registered
hcid[13445]: Can't init device hci0. Connection timed out(110)

The dongle works under XP SP2 just fine.  I thought at first that it
might be crippled, unable to do "real" bluetooth and supporting only the
Microsoft mouse & keyboard, but on my XP SP2 machine I'm able to see and
connect to my Sony Ericsson cellphone.  The dongle may still be
nonstandard in some way that breaks compatibility with bluez, but it is
at least known to work in XP SP2 to talk to non-MS equipment.

I hope that's enough information to help someone give me a clue as to
what to do for my problem.



-------------------------------------------------------
This SF.Net email is sponsored by:
Sybase ASE Linux Express Edition - download now for FREE
LinuxWorld Reader's Choice Award Winner for best database on Linux.
http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click
_______________________________________________
Bluez-users mailing list
Bluez-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-users

Re: [Bluez-users] Connection Timeout

[Marcel Holtmann]

[-- Attachment #1: Type: text/plain, Size: 1914 bytes --]

Hi Stephen,

> I'm a BT newbie having trouble with device timeouts using bluez.  I've
> seen this issue posted a few other places but no answers yet.  Some
> background:
> 
> I just bought a Microsoft BT mouse for a Win XP laptop and decided this
> afternoon to take it for a spin on my Linux box.
> 
> I've got kernel 2.6.8 (what gentoo calls 2.6.8.1-ck9; don't know where
> the .1 comes from but the ck9 refers to a set of desktop performance
> tuning patches they apply).
> 
> I applied patch-2.6.9-mh2 from http://www.bluez.org/patches.html and
> rebuilt my kernel and modules.

be carful with this, because these patches are only tested with the
kernel they are made for.

> The mouse came with a little USB dongle that has the following info on
> the backside:
> 
> "Wireless Transceiver for Bluetooth 2.0"
> Model: 1003
> IC: 3048A-1003
> 
> usbview shows the dongle with the name "Wireless Radio for Bluetooth",
> and its name is in red, which I've been led to believe means that no
> drivers have attached themselves to the device.  I don't know if that's
> important here or not.  I'd paste in the usbview output but usbview
> appears to not support whatever flavor of cut-and-paste gnome uses.
> I'll pull out any info someone asks me for (it's a big listing).  Here's
> the first several lines:
> 
> Manufacturer: Microsoft
> Serial Number: 0050F2E8E590
> Speed: 12Mb/s (full)
> USB Version: 1.10
> Device Class: e0(unk.)
> Device Subclass: 01
> Device Protocol: 01
> Maximum Default Endpoint Size: 64
> Number of Configurations: 1
> Vendor Id: 045e
> Product Id: 009c
> Revision Number: 1.00

This is the new dongle from Microsoft and it is now Broadcom based and
so you maybe need an additional patch to make it working. When it works,
send back the output from "hciconfig -a".

Btw I need this new desktop package from Microsoft for testing. Is there
anyone willing to donate one?

Regards

Marcel


[-- Attachment #2: patch --]
[-- Type: text/plain, Size: 545 bytes --]

===== drivers/bluetooth/hci_usb.c 1.58 vs edited =====
--- 1.58/drivers/bluetooth/hci_usb.c	2004-10-27 23:42:21 +02:00
+++ edited/drivers/bluetooth/hci_usb.c	2004-10-30 01:09:54 +02:00
@@ -103,6 +103,9 @@
 	/* Broadcom BCM2035 */
 	{ USB_DEVICE(0x0a5c, 0x200a), .driver_info = HCI_RESET | HCI_BROKEN_ISOC },
 
+	/* Microsoft Wireless Transceiver for Bluetooth 2.0 */
+	{ USB_DEVICE(0x045e, 0x009c), .driver_info = HCI_RESET | HCI_BROKEN_ISOC },
+
 	/* ISSC Bluetooth Adapter v3.1 */
 	{ USB_DEVICE(0x1131, 0x1001), .driver_info = HCI_RESET },
 

Re: [Bluez-users] Connection Timeout

[Stephen Quattlebaum]

(I combined responses to two responses to my original post in this
message.  Excuse the length, please: I included as much extra info as
seemed pertinent since I am apparently the first on this list to try one
of these new generation of MS mice.)

> > I applied patch-2.6.9-mh2 from http://www.bluez.org/patches.html and
> > rebuilt my kernel and modules.
> 
> be carful with this, because these patches are only tested with the
> kernel they are made for.
> 

I only got patch failures on two files, and both were trivial to merge
by hand.  Point taken, though.

> This is the new dongle from Microsoft and it is now Broadcom based and
> so you maybe need an additional patch to make it working. When it works,
> send back the output from "hciconfig -a".
> 
> Btw I need this new desktop package from Microsoft for testing. Is there
> anyone willing to donate one?
> 
> Regards

Your patch worked.  Thanks!

athene root # hciconfig -a
hci0:   Type: USB
        BD Address: 00:50:F2:E8:E5:90 ACL MTU: 377:10  SCO MTU: 16:0
        UP RUNNING PSCAN ISCAN
        RX bytes:38552 acl:1826 sco:0 events:404 errors:0
        TX bytes:6265 acl:155 sco:0 commands:106 errors:0
        Features: 0xff 0xfe 0x0d 0x38 0x08 0x08 0x00 0x00
        Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3
        Link policy: RSWITCH HOLD SNIFF PARK
        Link mode: SLAVE ACCEPT
        Name: 'BlueZ (0)'
        Class: 0x100100
        Service Classes: Object Transfer
        Device Class: Computer, Uncategorized
        HCI Ver: 1.2 (0x2) HCI Rev: 0x3 LMP Ver: 1.2 (0x2) LMP Subver:
0x800
        Manufacturer: Broadcom Corporation (15)


> Btw I need this new desktop package from Microsoft for testing. Is
> there anyone willing to donate one?

Would if I could!  I really shouldn't have even spent the money on
_mine_ right now... :-)

--- More Info and Questions ---

Now that the device is recognized, I have successfully synced w/ my T600
using multisync and gotten the mouse to work.  Buttons 3-5 and the
scrollwhell even work (though I still need to remap what they do...)
The mouse is still a little hokey, though.  Perhaps someone can help me
out here.  I think I know what's going on, but I don't know what, if
any, is the proper way to fix things.

1. hid2hci was not necessary.  As soon as I did "hciconfig hci0 up"
post-patch, the mouse immediately _stopped_ working until I got it to
work using hci below.  Apparently, when the dongle was initialized for
hci it stopped whatever hid jiggery it might have been doing (Henryk
hypothesized that it was spoofing itself as a standard USB mouse).  If
that is correct, I actually think it's a nice bit of behavior, since it
stops as soon as the OS proves that it knows what bluetooth is, thank
you very much.  A bit of random extra info, though: when the device was
in its apparent hid spoofing mode, there were _two_ extra mice devices
in /dev/input.  My USB mouse is mouse0, and "cat mouse2" proved that the
BT mouse was mouse2.  I don't know what mouse1 was... "cat mouse1" never
had any output when I moved either mouse.  Now that the mouse is working
in HCI mode, it's at /dev/input/mouse1 and I have no mouse2.

2. In order to get the mouse to work, (since it was earlier paired to an
XP SP2 machine, I'm guessing), I had to follow the instructions at
http://www.bueche.ch/comp/mx900/mx900.html (which is actually for a
logitek mouse, but worked).  I did "hidd --connect 00:50:f2:e8:fb:f2" to
"poke" the mouse, whereafter it started working.  Before I got to that
point, I had tried moving it back to the XP machine temporarily, and
ended up having to remove the mouse profile from that XP machine and
re-scan for it - not even a reboot of both the mouse (removing both
batteries) and the OS fixed it but the remove/rescan did.  The dongle
moved with the mouse when I switched computers (I only have one dongle
right now).  So, for both XP and Linux, I had to manually reconnect
before the mouse would work after talking to the other OS.  I don't
actually plan on moving this mouse between the two a lot, but I _could_
potentially have this mouse or another one like it on a USB KVM at some
point in the future, so this behavior dissapoints me a little.  I think
I understand - the mouse can only be paired to one PC at a time b/c
otherwise it'd be moving cursors on two screens at once if both are in
range, but surely there's an easy way to say, "you're on this PC now"
that doesn't involve remembering or looking up the device ID (or going
through the add/remove BT device wizard in XP).  I had hoped that the
mouse actually paired to the adapter, in which case it should, in
theory, work on a KVM, but its behavior makes it look like it pairs to
the PC.  Is that right?  Any suggestions on these issues?  (A pointer to
appropriate documentation will be more than sufficient, if I'm just
being blind :-) )

3. Right after I got the mouse working with HCI, I walked away from the
PC for a few minutes.  When I came back, the mouse wasn't working
anymore.  I know this mouse goes to sleep after a while, but at least on
the XP machine it wakes back up when you move it.  It didn't on linux,
and I had to use hidd to poke it again.  After that first time, however,
it hasn't happened again, even when I left it sitting for a while.
Weird behavior... should I expect to have to hidd-poke the mouse anytime
I walk away for a while?  (Surely not...)

4. usbview still shows the device as red, though it's working fine, so
here's independent verification of Henryk's observation that it
apparently doesn't matter.



Thanks a lot guys!



-------------------------------------------------------
This SF.Net email is sponsored by:
Sybase ASE Linux Express Edition - download now for FREE
LinuxWorld Reader's Choice Award Winner for best database on Linux.
http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click
_______________________________________________
Bluez-users mailing list
Bluez-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-users

Re: [Bluez-users] Connection Timeout

[Marcel Holtmann]

Hi Stephen,

> > This is the new dongle from Microsoft and it is now Broadcom based and
> > so you maybe need an additional patch to make it working. When it works,
> > send back the output from "hciconfig -a".
> 
> Your patch worked.  Thanks!
> 
> athene root # hciconfig -a
> hci0:   Type: USB
>         BD Address: 00:50:F2:E8:E5:90 ACL MTU: 377:10  SCO MTU: 16:0
>         UP RUNNING PSCAN ISCAN
>         RX bytes:38552 acl:1826 sco:0 events:404 errors:0
>         TX bytes:6265 acl:155 sco:0 commands:106 errors:0
>         Features: 0xff 0xfe 0x0d 0x38 0x08 0x08 0x00 0x00
>         Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3
>         Link policy: RSWITCH HOLD SNIFF PARK
>         Link mode: SLAVE ACCEPT
>         Name: 'BlueZ (0)'
>         Class: 0x100100
>         Service Classes: Object Transfer
>         Device Class: Computer, Uncategorized
>         HCI Ver: 1.2 (0x2) HCI Rev: 0x3 LMP Ver: 1.2 (0x2) LMP Subver:
> 0x800
>         Manufacturer: Broadcom Corporation (15)
> 

this Broadcom stuff is always a little bit problematic. If you like you
can test it without HCI_BROKEN_ISOC. Maybe they fixed their firmware now
and the SCO audio stuff works.

Oh and send in the output of "hcitool info ..." as root from the mouse
and the keyboard. And the results from "sdptest records ..." from the
libs2 CVS test directory would also be helpful.

> > Btw I need this new desktop package from Microsoft for testing. Is
> > there anyone willing to donate one?
> 
> Would if I could!  I really shouldn't have even spent the money on
> _mine_ right now... :-)

Anyone else who don't mind sending me another mouse and keyboard
combination?

> Now that the device is recognized, I have successfully synced w/ my T600
> using multisync and gotten the mouse to work.  Buttons 3-5 and the
> scrollwhell even work (though I still need to remap what they do...)
> The mouse is still a little hokey, though.  Perhaps someone can help me
> out here.  I think I know what's going on, but I don't know what, if
> any, is the proper way to fix things.
> 
> 1. hid2hci was not necessary.  As soon as I did "hciconfig hci0 up"
> post-patch, the mouse immediately _stopped_ working until I got it to
> work using hci below.  Apparently, when the dongle was initialized for
> hci it stopped whatever hid jiggery it might have been doing (Henryk
> hypothesized that it was spoofing itself as a standard USB mouse).  If
> that is correct, I actually think it's a nice bit of behavior, since it
> stops as soon as the OS proves that it knows what bluetooth is, thank
> you very much.  A bit of random extra info, though: when the device was
> in its apparent hid spoofing mode, there were _two_ extra mice devices
> in /dev/input.  My USB mouse is mouse0, and "cat mouse2" proved that the
> BT mouse was mouse2.  I don't know what mouse1 was... "cat mouse1" never
> had any output when I moved either mouse.  Now that the mouse is working
> in HCI mode, it's at /dev/input/mouse1 and I have no mouse2.

This thing is called HID Proxy and was invented by CSR. For these kind
of devices like the Logitech the switching is triggered by the tool
hid2hci, but Broadcom decided to trigger it on the HCI reset command. I
actually prefer the hid2hci approach, because sometimes the operating
system wants to switch to full Bluetooth mode later to get some time to
start some other services first.

Your device thing is input subsystem specific and I prefer to
use /dev/input/mice as common device for all attached mice.

> 2. In order to get the mouse to work, (since it was earlier paired to an
> XP SP2 machine, I'm guessing), I had to follow the instructions at
> http://www.bueche.ch/comp/mx900/mx900.html (which is actually for a
> logitek mouse, but worked).  I did "hidd --connect 00:50:f2:e8:fb:f2" to
> "poke" the mouse, whereafter it started working.  Before I got to that
> point, I had tried moving it back to the XP machine temporarily, and
> ended up having to remove the mouse profile from that XP machine and
> re-scan for it - not even a reboot of both the mouse (removing both
> batteries) and the OS fixed it but the remove/rescan did.  The dongle
> moved with the mouse when I switched computers (I only have one dongle
> right now).  So, for both XP and Linux, I had to manually reconnect
> before the mouse would work after talking to the other OS.  I don't
> actually plan on moving this mouse between the two a lot, but I _could_
> potentially have this mouse or another one like it on a USB KVM at some
> point in the future, so this behavior dissapoints me a little.  I think
> I understand - the mouse can only be paired to one PC at a time b/c
> otherwise it'd be moving cursors on two screens at once if both are in
> range, but surely there's an easy way to say, "you're on this PC now"
> that doesn't involve remembering or looking up the device ID (or going
> through the add/remove BT device wizard in XP).  I had hoped that the
> mouse actually paired to the adapter, in which case it should, in
> theory, work on a KVM, but its behavior makes it look like it pairs to
> the PC.  Is that right?  Any suggestions on these issues?  (A pointer to
> appropriate documentation will be more than sufficient, if I'm just
> being blind :-) )

The Broadcom guys are a little bit stupid and also implemented security
mode 3 for the mouse even if the HID specification said that this is not
really needed. So you must share your link key between the two operating
systems and that is the problem here.

> 3. Right after I got the mouse working with HCI, I walked away from the
> PC for a few minutes.  When I came back, the mouse wasn't working
> anymore.  I know this mouse goes to sleep after a while, but at least on
> the XP machine it wakes back up when you move it.  It didn't on linux,
> and I had to use hidd to poke it again.  After that first time, however,
> it hasn't happened again, even when I left it sitting for a while.
> Weird behavior... should I expect to have to hidd-poke the mouse anytime
> I walk away for a while?  (Surely not...)

Start "hidd --server" on boot and your mouse can reconnect.

> 4. usbview still shows the device as red, though it's working fine, so
> here's independent verification of Henryk's observation that it
> apparently doesn't matter.

I don't know what red means, but I wouldn't care. If the kernel says
that it works, everything is fine.

Regards

Marcel




-------------------------------------------------------
This SF.Net email is sponsored by:
Sybase ASE Linux Express Edition - download now for FREE
LinuxWorld Reader's Choice Award Winner for best database on Linux.
http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click
_______________________________________________
Bluez-users mailing list
Bluez-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-users

Re: [Bluez-users] Connection Timeout

[Henryk Plötz]

Moin,

On Fri, 29 Oct 2004 17:50:55 -0500, Stephen Quattlebaum
<stephen@covidimus.net> wrote:

> I just bought a Microsoft BT mouse for a Win XP laptop and decided this
> afternoon to take it for a spin on my Linux box.

I've got one myself and found it significantly more complicated to get
to run under Windows than under Linux.

> "Wireless Transceiver for Bluetooth 2.0"

Interesting. Mine lacks the "2.0" addition, so yours is probably a newer de=
vice.

> usbview shows the dongle with the name "Wireless Radio for Bluetooth",

It says "Wireless Transceiver for Bluetooth" here.

> and its name is in red, which I've been led to believe means that no
> drivers have attached themselves to the device.  I don't know if that's
> important here or not.

Probably not. The aforementioned Microsoft-Dongle as well as my
Laptop's integrated Bluetooth both show red in usbview, and both work
with BlueZ.

> I'd paste in the usbview output but usbview
> appears to not support whatever flavor of cut-and-paste gnome uses.

You did try to simply select in usbview (left mouse button) and paste
in whatever other application (middle mouse button or left and right
mouse buttons simultaneously if you don't have a middle button), did
you? Because that just works for me and my usbview.

> When I plug in the dongle, the mouse just starts working without me
> having to do anything at all (though some of the buttons don't work,
> even the scrollwheel, which is working on another USB mouse attached to
> this system).

This is Not Good[tm]. It probably means that your newer version of the
dongle is capable of handling HID connections itself (until now I
thought only Logitech's would do that) and thus probably spoofing to
be just some random USB mouse to your computer.

> athene bluetooth # hciconfig
> hci0:   Type: USB
>         BD Address: 00:00:00:00:00:00 ACL MTU: 0:0  SCO MTU: 0:0
>         DOWN

This reinforces my belief. You surely can't have a Bluetooth HID
connection when your Bluetooth device is down.

I guess you probably need to do what all those users of the Logitech
Wireless Hub do: Use hid2hci to switch the dongle from "Let's pretend
I was a mouse" mode over to "Yet another boring Bluetooth dongle"

--
Henryk Pl=F6tz
Gr=FC=DFe aus Berlin


-------------------------------------------------------
This SF.Net email is sponsored by:
Sybase ASE Linux Express Edition - download now for FREE
LinuxWorld Reader's Choice Award Winner for best database on Linux.
http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click
_______________________________________________
Bluez-users mailing list
Bluez-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-users

Re: [Bluez-users] Connection Timeout

[Jouni.Lohikoski@iki.fi]

On Fri, Oct 29, 2004 at 05:50:55PM -0500, Stephen Quattlebaum wrote:
> usbview shows the dongle with the name "Wireless Radio for Bluetooth",
> and its name is in red, which I've been led to believe means that no
> drivers have attached themselves to the device.  I don't know if that's
> important here or not.  I'd paste in the usbview output but usbview
> appears to not support whatever flavor of cut-and-paste gnome uses.

Try lsusb as root.
# lsusb --vv

// jouni




-------------------------------------------------------
This SF.Net email is sponsored by:
Sybase ASE Linux Express Edition - download now for FREE
LinuxWorld Reader's Choice Award Winner for best database on Linux.
http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click
_______________________________________________
Bluez-users mailing list
Bluez-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-users