Hi Arman, On Wed, Nov 19, 2014, Arman Uguray wrote: > I now have a few of questions before I start implementing anything: > > 1. I'm confused about how the current code handles the case where > hci_connect_le returns -EBUSY while handling an advertisement report. > The code simply ignores the error and hci_conn object gets created, so > the next time an advertisement report gets received and we call > hci_connect_le, won't that just return early since > hci_conn_hash_lookup_ba will return something? How will this actually > ever get to adding the LE Create Connection request? Regarding advertising reports while there's a connect attempt in progress, hci_connect_le() disables advertising before issuing HCI_LE_Create_Conn so advertising should never be active while we're trying to connect. Only once the connection times out or we're successfully connected does advertising get re-enabled and we're ready again to connect any other device that might be around. Regarding conn objects stuck in BT_CONNECT, the state is only set to that later in hci_connect_le() when calling hci_req_add_le_create_conn() i.e. when we know we can issue the command, so I don't see any obvious problems here. > 2. The background scan code currently assigns ownership of the > hci_conn structure to the hci_conn_params structure that triggered it. > I guess it's OK if a reference is held both by the parameters AND the > l2cap_conn structure if this is triggered by an L2CAP connect instead? I don't see any problems in having multiple references like this. > 3. The background scan code currently passes BT_SECURITY_LOW to > hci_connect_le, but we probably need a way to obtain the security > level from the l2cap sock options in the l2cap connect case. What's > the best way to pass this data along? The first thing that comes to mind is to add an extra u8 sec_level variable to the hci_conn_params struct. Johan -- To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
