hci.c will only accept incoming connections in Slave role

[GoogleCodeExporter]

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.

Original issue reported on code.google.com by soul.cak...@gmail.com on 14 Oct 2014 at 11:00

[GoogleCodeExporter]

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?

Original comment by matthias.ringwald@gmail.com on 15 Oct 2014 at 11:59

• Changed state: Accepted