Return-Path: Date: Thu, 20 Nov 2014 11:34:03 +0200 From: Johan Hedberg To: Arman Uguray Cc: Marcel Holtmann , BlueZ development , Jakub Pawlowski Subject: Re: Handling EBUSY for LE connections. Message-ID: <20141120093403.GA20651@t440s.lan> References: <50181A20-3313-48C7-924B-05C67B975139@holtmann.org> <7ED5AE30-EF53-47EA-A9CE-DD371CE10910@holtmann.org> <20141119212751.GA6364@t440s.P-661HNU-F1> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: List-ID: 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