Received-SPF: pass (google.com: best guess record for domain of linux-bluetooth-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
From:   "=?utf-8?Q?Micha=C5=82?= Lowas-Rzechonek" 
        <michal.lowas-rzechonek@silvair.com>
Date:   Thu, 6 Feb 2020 18:16:00 +0100
To:     linux-bluetooth@vger.kernel.org
Cc:     brian.gix@intel.com, inga.stotland@intel.com
Subject: mesh: Missing API for delivering provisioning public key via OOB?
Message-ID: <20200206171600.227uzfonhepltydy@kynes>
Mail-Followup-To: linux-bluetooth@vger.kernel.org, brian.gix@intel.com,
        inga.stotland@intel.com
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
User-Agent: NeoMutt/20180716
Sender: linux-bluetooth-owner@vger.kernel.org
Precedence: bulk

Hi,

I have been playing with mesh-cfgclient, and I've noticed that
provisioning procedure gets stuck when node reports Public Key OOB
information available' in 'Public Key Type' field of Provisioning
Capabilities PDU.

While digging into the code and API, I think we have a missing feature
in the API between provisioner application and the daemon - while there
is an API to deliver OOB keys to the daemon when *the application* is
being provisioned, there doesn't seem to be a way to deliver provisioned
device's public key when is the application who does the provisioning.

Is my understanding correct, or is there something I've missed?

regards
-- 
Michał Lowas-Rzechonek <michal.lowas-rzechonek@silvair.com>
Silvair http://silvair.com
Jasnogórska 44, 31-358 Krakow, POLAND