Return-Path: From: Szymon Janc To: jaikumar Ganesh Subject: Re: [PATCH 3/4] Add DBus OOB API documentation. Date: Mon, 15 Nov 2010 11:11:38 +0100 Cc: "linux-bluetooth@vger.kernel.org" References: <1288865461-3760-1-git-send-email-szymon.janc@tieto.com> <20101112182921.GA15584@jh-x301> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Message-Id: <201011151111.38772.szymon.janc@tieto.com> Sender: linux-bluetooth-owner@vger.kernel.org List-ID: Hi, > So the only APIs added are these provider ones and one API in Agent > code for approval. > > So how does bluetoothd decide whether OOB is present for a particular > remote device for an outgoing pairing case ? Just on the basis of > whether a provider is registered or am I missing something here. If there is an active OOB plugin then it is asked for remote OOB data when io capabilities are established. Based on the answer oob_data field in io capability reply is set. Dbus OOB plugin becomes active when provider is registered. If no oob plugin is active oob_data field is always set to 0x00. > RequestRemoteOobData is called before initiating pairing or when the > remote end asks for the OOB data ? > Its unclear from the API description. I can see that OOB mechanism is somewhat unclear, let me try to clarify: - local oob data are data generated by local adapter - remote oob data are data received from remote device - remote and/or local data are exchange through some OOB mechanism - this takes place before SSP is started (note that data exchanged on OOB also contains BT address) - during SSP active oob plugin is asked for oob data for remote device So, RequestRemoteOobData is called when io capabilities are being established, but this asks plugin if it already has OOB data for this device and not a remote device to provide this data. Hope this clarifies things a bit :) -- Szymon Janc