From: Art Rothstein <art@mojo-working.com>
To: Bluez-devel <bluez-devel@lists.sourceforge.net>
Subject: [Bluez-devel] Role switch: Detecting, predicting, preventing
Date: Wed, 14 Feb 2007 22:04:52 -0800 [thread overview]
Message-ID: <45D3F804.5030601@mojo-working.com> (raw)
I am running two BTPROTO_RFCOMM applications on a PC with Ubuntu 2.6.17-11-386,
each bound to its own USB dongle. One is a client, the other a server. Both
use the existing link mode settings of SLAVE ACCEPT. Yet an Accept Connection
Request (traced with hcidump) shows Role Master, and the client receives a Role
Change.
If I put the same application, with the same USB dongles, on a PC running
Xubuntu 2.6.17-10-generic, the server's Accept Connection Request shows Role
Slave, and the Role Change packet does not flow.
My questions:
(1) What causes the role switch?
(2) Can I detect the role switch programmatically after it has occurred? Both
hci_devinfo and getsockopt( s, SOL_RFCOMM, RFCOMM_LM, ... ) claim the server is
still a slave.
(3) Can I predict the role switch before it occurs? Again, hci_devinfo and
getsockopt provide no clues.
(4) Can I programmatically instruct the 2.6.17-11-386 server not to perform the
role switch? If hci_devinfo is already set to SLAVE, calling
ioctl(HCISETLINKMODE) sounds unpromising.
What makes the role switch interesting, and undesirable, is that several
Bluetooth devices (all devices with link manager 1.x?) are limited to two slave
connections. A third Create Connection fails with Command Disallowed, reflected
to the Linux client application as "File descriptor in bad state".
As for motivation, I plan to use one Linux PC with lots of dongles to model the
behavior of a large piconet. A configuration that includes PCs running
Microsoft's stack, or Macs running Apple's stack, is stuck with the role switch,
but there are lots of configurations that use only peer-friendly devices.
-----
McKinley Systems
San Francisco
415-827-7575
http://www.mojo-working.com
-------------------------------------------------------------------------
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
next reply other threads:[~2007-02-15 6:04 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-02-15 6:04 Art Rothstein [this message]
2007-02-15 8:18 ` [Bluez-devel] Role switch: Detecting, predicting, preventing Marcel Holtmann
2007-02-15 23:30 ` Art Rothstein
2007-03-02 17:35 ` Art Rothstein
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=45D3F804.5030601@mojo-working.com \
--to=art@mojo-working.com \
--cc=bluez-devel@lists.sourceforge.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.