Re: [Bluez-users] concurrent calls to RFCOMM connect()

Andrea Galbusera
2007-11-27T08:03:05Z

Hi Marcel,

On Nov 26, 2007 6:36 AM, Marcel Holtmann <marcel@holtmann.org> wrote:
> a small comment up-front. Top-posting is not a good way of getting my
> attention. Check http://www.bluez.org/lists.html

You are obviously right! I apologize to you and other users of the
list for the inconvenience. That was accidental and was not intended
as a way to catch more attention. I understand that some of my
questions may sound silly to you and other bluez developers, but I
don't have a wireless communication background and I'm trying to
approach bluetooth from the application level.

> It takes 20 seconds, because that is the page timeout of your local
> hardware. You can change it with "hciconfig hci0 pageto". You can also
> play with the link supervision timeout to faster detect a link loss.
> Please remember that a shorter value also has disadvantages.

I will search more on these timeouts and the pro/cons of changing
them. Maybe tuning them will suffice.

> It serializes connection attempts to different remote devices. If you
> try to connect to the same remote device (by opening the same TTY twice)
> then you are out of luck. The kernel is not doing anything here.

My question was not clear enough... In my test I try to connect to a
different remote address while in progress with the first one (both
powered off). I do it like this:

Terminal 1:
$> rfcomm connect 00:01:95:07:30:EA

Terminal 2 (while the first attempt is in progress):
$> rfcomm connect 00:01:95:07:30:40
Can't connect RFCOMM socket: Device or resource busy

Does it mean my kernel and/or my bluez-utils are too old to queue
connection attempts?

> You need to read the specification since clearly you are guessing here
> behavior. The various timeouts can be configured. Or maybe get a book
> that explains the basics behind the Bluetooth radio.

I'm going to follow your suggestions, even if I believe the
specification is too intricated for me. Maybe a book is a better
choice. Thanks for patience.

Regards,
Andrea