This isn't so much a bug as a gotcha-note. This may have some bearing on compatibility issues with, for example, knockoff PS3 controllers. Or not.

What steps will reproduce the problem? 1. Build an app with hci.c as well as an upper packet handler, for example using BTdaemon. 2. Attempt to initiate a connection from a paired peripheral like Apple BT keyboard

What is the expected output? What do you see instead? A stable connection should be established. Instead, the keyboard issues a disconnect 100ms after Read Remote Supported Features Complete. This can be traced to the use of role 0x1 with hci_accept_connection_request; changing this to role 0 (changing to master) in hci.c works flawlessly.

What version of the product are you using? On what operating system? svn trunk on Linux 3.x.

and provide any additional information below.

This can be handled by manually changing the role on receipt of the Read Supported Features Complete event. However, trying to issue the command from the Connection Complete handler causes the daemon to crash. Is this expected behaviour? The daemon seems to have issues with multiple simultaneous commands, and I can't see if I'm just missing the docs.

Hi.

As we're slave already, not changing to master seems to be the safe approach. I can see the need for a global flag that enforces master role (e.g. if we're a laptop), but it should still be possible to change the role after the connection is complete. No, daemon isn't suppose to crash. Daemon is fine processing one hci command after the other. What does crash?