public inbox for linux-bluetooth@vger.kernel.org
 help / color / mirror / Atom feed
* [Bluez-devel] Error connecting after inquiry
@ 2007-04-12  3:05 Donnie Smith
  2007-04-12  7:46 ` Marcel Holtmann
  0 siblings, 1 reply; 6+ messages in thread
From: Donnie Smith @ 2007-04-12  3:05 UTC (permalink / raw)
  To: bluez-devel


[-- Attachment #1.1: Type: text/plain, Size: 1505 bytes --]

Hello,
I am developing an application that connects to the Nintendo Wii remote,
which is a bluetooth device, using BlueZ.  The API allows a bdaddr to be
supplied, or not.  If it is not supplied, the API invokes a search function
that does an hci_inquiry to get all available devices, hci_open_dev to get a
device connection, then traverses the array, calling hci_remote_name and
checking the class for each item returned from hci_inquiry until a Wiimote
is found, closes the hci device, and returns the bdaddr of the Wiimote.  The
calling function then opens a couple of L2CAP sockets and proceeds to
communicate with the device.

Here's my problem: many users receive errors on the L2CAP socket open only
when a bdaddr is not supplied, but it works fine when the bdaddr is provided
(thus skipping the search procedure described above).  I've verified that
the bdaddr returned by the search function is, in fact, identical to that
supplied, so the parameters to the socket open call are identical.  It
happens every time on some machines, and never on others - to my knowledge,
there are no intermittently failing machines.  Any ideas?

The calling function is cwiid_connect, listed in
http://abstrakraft.org/cwiid/browser/trunk/libcwiid/connect.c
The search function is cwiid_find_wiimote, which calls
cwiid_get_bdinfo_array, both listed in
http://abstrakraft.org/cwiid/browser/trunk/libcwiid/bluetooth.c

Thanks for any help you can provide,
L. Donnie Smith
CWiid Developer
http://abstrakraft.org/cwiid

[-- Attachment #1.2: Type: text/html, Size: 1781 bytes --]

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

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

[-- Attachment #3: Type: text/plain, Size: 164 bytes --]

_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [Bluez-devel] Error connecting after inquiry
  2007-04-12  3:05 Donnie Smith
@ 2007-04-12  7:46 ` Marcel Holtmann
  0 siblings, 0 replies; 6+ messages in thread
From: Marcel Holtmann @ 2007-04-12  7:46 UTC (permalink / raw)
  To: BlueZ development

Hi Donnie,

> I am developing an application that connects to the Nintendo Wii
> remote, which is a bluetooth device, using BlueZ.  The API allows a
> bdaddr to be supplied, or not.  If it is not supplied, the API invokes
> a search function that does an hci_inquiry to get all available
> devices, hci_open_dev to get a device connection, then traverses the
> array, calling hci_remote_name and checking the class for each item
> returned from hci_inquiry until a Wiimote is found, closes the hci
> device, and returns the bdaddr of the Wiimote.  The calling function
> then opens a couple of L2CAP sockets and proceeds to communicate with
> the device. 
> 
> Here's my problem: many users receive errors on the L2CAP socket open
> only when a bdaddr is not supplied, but it works fine when the bdaddr
> is provided (thus skipping the search procedure described above).
> I've verified that the bdaddr returned by the search function is, in
> fact, identical to that supplied, so the parameters to the socket open
> call are identical.  It happens every time on some machines, and never
> on others - to my knowledge, there are no intermittently failing
> machines.  Any ideas? 

run "hcidump -X -V" as root to see what actually happens. You are using
threads and this might be a simply race condition.

However you also resolve the names for devices that don't have the
Wiimote device class. That is not needed at all. And a failing name is
not a reason to abort the whole search procedure. It can happen.

And you might wanna thing about doing this with our D-Bus API since it
is doing everything for you. Including telling you the RSSI values so
you can pick the one really next to you.

Regards

Marcel



-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [Bluez-devel] Error connecting after inquiry
@ 2007-04-12 19:42 Donnie Smith
  2007-04-12 20:13 ` Marcel Holtmann
  0 siblings, 1 reply; 6+ messages in thread
From: Donnie Smith @ 2007-04-12 19:42 UTC (permalink / raw)
  To: bluez-devel


[-- Attachment #1.1: Type: text/plain, Size: 646 bytes --]

While it is a multi-threaded library, no other threads are started until
after the connection is made.

You raise a good point about checking the name for all devices.  Thanks.

We've narrowed the problem down to the hci_remote_name call - if we filter
on device class alone, and never request the name, the connection works.
Are there any connections opened by hci_remote_name that need to be
explicitly closed?  Would checking device class alone be sufficient?  From
what I've read, device class is determined by capabilities, and isn't
guaranteed to be unique to the Wiimote.

I'll take a look at the D-Bus API.


Thanks for your help,
Donnie

[-- Attachment #1.2: Type: text/html, Size: 718 bytes --]

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

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

[-- Attachment #3: Type: text/plain, Size: 164 bytes --]

_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [Bluez-devel] Error connecting after inquiry
  2007-04-12 19:42 [Bluez-devel] Error connecting after inquiry Donnie Smith
@ 2007-04-12 20:13 ` Marcel Holtmann
  0 siblings, 0 replies; 6+ messages in thread
From: Marcel Holtmann @ 2007-04-12 20:13 UTC (permalink / raw)
  To: BlueZ development

Hi Donnie,

> We've narrowed the problem down to the hci_remote_name call - if we
> filter on device class alone, and never request the name, the
> connection works.  Are there any connections opened by hci_remote_name
> that need to be explicitly closed?  Would checking device class alone
> be sufficient?  From what I've read, device class is determined by
> capabilities, and isn't guaranteed to be unique to the Wiimote. 

the remote name request creates a temporary baseband connection and in
that case no other connection request will succeed. Reducing the timeout
for the remote name function is not helping here since it won't send the
remote name cancel in case of a timeout. This is probably a bug in the
library, but also not easy to handle since that command is not always
available.

So first of all you should only request the name for devices with the
correct class (since the others don't matter at all). Then you need to
use a bigger timeout. The name request can take some time. The baseband
needs to page the other side.

Other than that you can add a sleep(1) re-try the connect if it failed.

Regards

Marcel



-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

^ permalink raw reply	[flat|nested] 6+ messages in thread

* [Bluez-devel] Error connecting after inquiry
@ 2007-04-14 16:01 Donnie Smith
  2007-04-18 23:49 ` Marcel Holtmann
  0 siblings, 1 reply; 6+ messages in thread
From: Donnie Smith @ 2007-04-14 16:01 UTC (permalink / raw)
  To: bluez-devel


[-- Attachment #1.1: Type: text/plain, Size: 151 bytes --]

Ok, the name is now only checked for devices that pass the class filter.
Is there any way to ensure the baseband connection is closed?

Thanks,
Donnie

[-- Attachment #1.2: Type: text/html, Size: 167 bytes --]

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

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/

[-- Attachment #3: Type: text/plain, Size: 164 bytes --]

_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [Bluez-devel] Error connecting after inquiry
  2007-04-14 16:01 Donnie Smith
@ 2007-04-18 23:49 ` Marcel Holtmann
  0 siblings, 0 replies; 6+ messages in thread
From: Marcel Holtmann @ 2007-04-18 23:49 UTC (permalink / raw)
  To: BlueZ development

Hi Donnie,

> Ok, the name is now only checked for devices that pass the class
> filter.
> Is there any way to ensure the baseband connection is closed?

I might have to fix that inside the kernel. A remote name complete event
should trigger a re-iteration of pending connect requests. This is not
simple. However you can call a remote name cancel command before
actually connecting to the device.

However the best for you is to use a high timeout for the name request
function. This will ensure that you catch the remote name complete
events and not abort before that. Use the values we use in hcitool,
because they are this long for a reason.

Regards

Marcel



-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2007-04-18 23:49 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2007-04-12 19:42 [Bluez-devel] Error connecting after inquiry Donnie Smith
2007-04-12 20:13 ` Marcel Holtmann
  -- strict thread matches above, loose matches on Subject: below --
2007-04-14 16:01 Donnie Smith
2007-04-18 23:49 ` Marcel Holtmann
2007-04-12  3:05 Donnie Smith
2007-04-12  7:46 ` Marcel Holtmann

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox