Hi Johan, > On Wed, Nov 19, 2014 at 1:27 PM, Johan Hedberg <johan.hedberg@xxxxxxxxx> wrote: > Hi Arman, > > On Mon, Nov 17, 2014, Arman Uguray wrote: >> >> I guess I'm seeking some programming advice now as a net/bluetooth >> >> noob. So it looks like in l2cap_code.c:l2cap_chan_connect I want to >> >> replace the call to "hci_connect_le" with some variant of >> >> hci_conn_params_set. Based on my understanding, eventually if an ADV >> >> report is received, hci_event.c:process_adv_report will handle >> >> creating the connection for us (in hci_event.c:check_pending_le_conn). >> >> >> >> From here, what would be the best (and proper) way to propagate this >> >> information and the newly created hci_conn structure to the l2cap >> >> layer so that the l2cap_conn structure can be set up? >> > >> > that is a good question. I think Johan is a bit deeper in the code. >> > Might worthwhile to jump on IRC and brainstorm with him on this. >> > >> >> I'm pretty much always out of luck getting ahold of people on IRC, so >> hopefully Johan will see this thread and respond eventually. >> >> > He has done connection creation for the slave side using direct >> > advertising and that would have some similar logical handling. At >> > least I think it does. And if not, we might first need a few >> > cleanups to make the LE connection handling for L2CAP sockets more >> > streamlined and easy to integrate. >> > >> >> So, from looking at the code, I see that l2cap_sock_connect calls >> l2cap_chan_connect, which internally creates the hci_conn via >> hci_connect_le. If all goes well, l2cap_sock_connect simply sits and >> waits until the socket state becomes BT_CONNECTED. So, I guess we may >> want something similar to that. We could revise hci_connect_le so that >> it automatically creates the temporary whitelist entry and listens for >> AD. Or perhaps we could have an additional API that sends an LE Create >> Connection that accepts an hci_conn instead of an hci_dev, which can >> then be called from hci_event.c:check_pending_le_conn. >> >> Anyway, I think I have a rough idea of what needs to be done overall >> but I'd appreciate Johan's input. > > It sounds like you're pretty much on the right track. Creating a > temporary entry to the same list that's used for the usual passive > scanning based connections should work. All other code that deals with > notifying the l2cap_chan once we get the LE_Connection_Complete event > should already be there and do the right thing, so the only new thing > that should be needed at that point is to permanently remove the > temporary entry you added. > > Anyway, this is what I *think* should work. Once you have some initial > patches ready it'll be easier to see how things really are :) > 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? 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? 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? > Johan Thanks! Arman -- 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
