Ticket #31 (assigned defect)

Opened 10 years ago

Last modified 6 years ago

BlueZ connection timing issues

Reported by: dsmith Owned by: dsmith
Priority: major Milestone: Version 0.6.00
Component: libcwiid Version:
Keywords: Cc:


For some people, automatic wiimote discovery never works. For more details, see:

Change History

  Changed 10 years ago by dsmith

  • status changed from new to assigned

  Changed 10 years ago by djh

  • version 0.5.02 deleted

I'm running Suse 10.2 on an AMD64 (bluez-libs 3.7-14.1-x86-64) cwiid is cwiid-0.5.03

I have the symptoms of this problem:

$ wmdemo/wmdemo 
Put Wiimote in discoverable mode now (press 1+2)...
0:Error opening control channel
Unable to connect to wiimote

If I run wmgui, I get the same error. If I supply the bdaddr on the command line, it works. Perhaps interesting is that if I disconnect in wmgui once it has connected and then reconnect from the menu, it works.

Other info:

$ lswm -al
Put Bluetooth devices in discoverable mode now...
00:1A:E9:3C:C7:1E 0x002504 Nintendo RVL-CNT-01

I'll be happy to do whatever I can to help resolve this issue.

Cheers, Dave

follow-up: ↓ 4   Changed 10 years ago by dsmith

It appears what is happening in at least some of the problem machines is that libcwiid sends a name request to the potential Wiimote devices (as determined by their Bluetooth device class), and that the baseband connection created to handle the name request is hanging around for awhile, blocking any other connection attempts.

Marcel's (the BlueZ guy) suggestion was to increase the timeout on the name request. I don't really understand why that would help, but then I don't care to understand BlueZ internals right now, so I'll take his word for it. This value has been doubled (to 10 seconds) in /branches/dev. If you're interested in helping resolve this, I'll be glad to work with you on it - just check out the code and let me know how it works, and we'll go from there.

Other solution possibilities include eliminating the name check (How many other devices share the Wiimote's bluetooth class?), and retrying the connection. These should be implemented as flags and options rather than default behaviors.

in reply to: ↑ 3   Changed 10 years ago by valdar

Replying to dsmith:

I'have try the dev branch but nothing is changed here: same problem same symptoms.

follow-up: ↓ 6   Changed 10 years ago by dsmith

You may try playing with the timeout parameter to hci_remote_name (libcwiid/bluetooth.c, line 126). Try higher and lower values - maybe as low as 100, up to 100000. I don't really understand how larger values could affect it, as the whole search and connection process takes place in less than 10 seconds (the current value), but it's worth a try.

in reply to: ↑ 5 ; follow-up: ↓ 7   Changed 10 years ago by anonymous

I tried playing with the timeout a little, also without result. Looking at the code, I decided to try a sledgehammer, so in wiimote/connect.c I added a delay:

        /* If BDADDR_ANY is given, find available wiimote */
        if (bacmp(bdaddr, BDADDR_ANY) == 0) {
                if (wiimote_find_wiimote(bdaddr, 2)) {
                        goto ERR_HND;

That fixes it :)

I'm guessing that things take some time to settle down after hci_close_dev(sock) is called in wiimote/bluetooth.c but really I've no idea what's going on

HTH, Dave

in reply to: ↑ 6   Changed 10 years ago by valdar

This solution do the trick!!! It worked also for me.

  Changed 10 years ago by dsmith

It is a sledgehammer solution, as you put it, but as long as this problem has been around, I'll take whatever works. I'll commit it, hopefully tonight.


  Changed 10 years ago by dsmith

done r126

I'm going to leave the ticket open in case a better fix comes along, although I imagine the real fix is a bluez patch.

  Changed 10 years ago by dgoemans

Mine has been working almost flawlessly, up until about a few mins ago. I have been pretty much coding solid for a day or two, and if the Socket connect error (control channel) came up ( which it did once or twice ) i would just unplug and replug my bluetooth adapter. But now it has stopped working completely, i get that error no matter what. I even went into connect.c, added more of a delay, and still nothing. Really sad. Btw, congrats, I found cwiid had been added to the openSuse repositories, i am very glad about this :D

  Changed 10 years ago by dgoemans

This is odd.. My wmgui is working fine, but my app is failing to connect.

char reset_bdaddr = 0;

if (bacmp(&m_bdaddr, BDADDR_ANY) == 0) 
  reset_bdaddr = 1;
if ((m_wiiMote = cwiid_open(&m_bdaddr, CWIID_FLAG_MESG_IFC)) == NULL) 
  printf("Unable to connect\n");
else if ( cwiid_set_mesg_callback( m_wiiMote, &CallBack ) ) 
  printf("Error setting callback\n");
  if (cwiid_close(m_wiiMote)) 
    // Do Nothing
  m_wiiMote = NULL;

It fails in cwiid_open() If i were to pass in an address with m_bdaddr, would that help? Let me check


  Changed 10 years ago by dgoemans

I added in the following line

m_bdaddr = *BDADDR_ANY;


if (bacmp(&m_bdaddr, BDADDR_ANY) == 0) 
  reset_bdaddr = 1;

and its fine. I must have stupidly deleted it somehow. Altho I'm certain it didn't seem to need that before. Oh well, my bad


  Changed 9 years ago by yabbas

I think this is because hci_read() fails in retreiving the friendly device name [this happens on the Nokia N800/N810 too under OS2008 - not sure if it's a bug in BlueZ].

I've used DBus methods to successfully query friendly names.

  Changed 9 years ago by add

about their apps in the first place. Both annotations and contributions will only clutter the interface by default as a design pattern rather than trying to put it all together. That way you can never create offline or print docs of high quality without again having the devs or current admins maintain the comments and annotations. Hopefully a small Wiki quality team will evolve (i am against ops or admins) to review and summarize the contributions. I hope this gives us more users as contributors than having the docs focused on the devs. Cheers, duns  china tour  Apparel  shoes  bags  Kitchen  Food and Wine  Furniture)  Flowers and Gifts  Wall Art  Computer Components I still prefer a wiki like approach since the php (or mysql) docs are very cluttered when you have to take their comments in account. On the other hand they are professionally maintained imho, since they are *much* better than KDE documentation. KDE is by far larger and has so many different apps, which need screenshots and end user not dev/api docs, that more help is needed as long as the devs prefer to code than to write nice docs. And it is their choice to some degree imo. Technically interested but non-dev end users, which are plenty out there, are the users of and the best contributers to the docs

  Changed 8 years ago by buhochileno

I work succesfully with wiimote on my Fedora 8 machine with cwiid 0.6 from sources and RPM's, now I move to fedora 10 (exact same machine) and sorprisly is not working!!, is the same discovery problem mentioned in this ticket, I try with fedora 10 cwiid rpms and also with last cwiid svn sources...I also try all as root to see if it a permision issue and even try giving the mac address to wminput with same results..

To me it seems like a diference in the way tha fedora 10 treat the bluetooth adapter, on fedora 8, the adapter have the light allways on, on fedora 10 the the bluetooth adapter have the light allways blinking, may be fedora 10 set the bluetooth adapter to some "autp-discovery" or other mode incompatible for cwiid?..

Any ideas, sugestions where to start to digg in...



  Changed 8 years ago by jamieee

  Changed 8 years ago by jamieee

  Changed 8 years ago by dsmith

No idea - are you sure that it's the same timeout issue?

In other news, the sleep(1), while working, is annoying - I'd like to find out if it works without the sleep with later versions of bluez, and test versions to remove it when possible.

  Changed 8 years ago by dsmith

  • summary changed from Wiimote discover problem to BlueZ connection timing issues

  Changed 7 years ago by bascorp

  Changed 6 years ago by davesilva

Note: See TracTickets for help on using tickets.