Hi Szymon: On Tue, Nov 16, 2010 at 2:12 AM, Szymon Janc <szymon.janc@xxxxxxxxx> wrote: >> >> Why are we enforcing this limitation ? >> > >> > Spec requires that each hash&randomizer values should be used only for one OOB >> > transfer. Implementation enforces that by allowing only one active OOB plugin >> > at time and DBUS OOB plugin only 'expose' plugin API over DBUS. So this >> > limitation is a consequence of that. >> >> I don't think the spec says that. It just says every single time the >> call to read the local adapters hash >> and randomizer is done you get new values. You can use the value that >> you have obtained for as many OOB pairings >> as you wish. > > Please see note in Vol2. Part E. 7.3.60: > > "Each OOB transfer will have unique C and R values so after each OOB > transfer this command shall be used to obtain a new set of values for the next > OOB transfer." > Yes we were talking about the same thing, just at different layers. I was talking about it from the user of the provider. This looks fine to me. > > -- > Szymon Janc > -- 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