Hi Brian, Sorry for the delay, On 15:09 Thu 17 Mar, Brian Gix wrote: > > Hi Vinicius, > > As you probably know, I am working on adding mgmt.c plumbing into > SMP, to enable user level input (Confirmation, passkeys, perhaps > OOB). > I didn't know. Cool. > One issue I am running into is matching up the return of user > confirmation with the (struct l2cap_conn *). There is nothing > within the user confirmation aside from the bdaddr that identifies > who it is intended for, and there is no one-to-one relationship > between bdaddrs and L2CAP channels. > Yeah, I can see why this is a problem. > What would you think about enforcing a "one at a time" SMP process? > Short answer: seems easier to get right, but a little ugly. Long answer below, opinions welcome. > The SMP pairing data within the l2cap_conn structure is certainly a > handy place for it, however it is bulky for the times (most of the > time) where SMP is *not* taking place, and as in the obvious case I > mention above, there is not a handy way to track the L2CAP > connection back to the user input. I agree that this information needs to be grouped and moved somewhere else. Something similar to l2cap_pinfo? smp_pinfo perhaps? > > I would like to suggest that all of the SMP data be pulled out of > the l2cap_conn structure, and put into a private structure within > smp.c. It can be malloc'd when the pairing process starts, free'd > when it completes, and any traffic (from either the User or the > Baseband) that takes place when another device is in the midst of > pairing gets rejected. This sounds very tempting, but I don't think that imposing this restriction from kernel side is the right aproach, the only hard limitation that I can imagine is user interaction. And if we use Just Works even that limitation is droped. One question: what were your plans for dealing with multiple adapters? Btw, it would be great if we could maintain a similar behaviour to Basic Rate. > > This structure local to smp.c would store both the bdaddr (to match > up with user input) and the l2cap_conn * to match up with BB > traffic, and provide the outbound path for the user confirmation > which would otherwise be difficult to track down. It would be a little harder but we could do something similar to l2cap when it's needed to find a socket associated with a connection. > > Your Thoughts? > > -- > Brian Gix > bgix@xxxxxxxxxxxxxx > Employee of Qualcomm Innovation Center, Inc. > Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum Cheers, -- Vinicius -- 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
