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;
Date:   Mon, 1 Jul 2019 22:00:24 +0200
From:   "michal.lowas-rzechonek@silvair.com" 
        <michal.lowas-rzechonek@silvair.com>
To:     "Gix, Brian" <brian.gix@intel.com>
Cc:     "linux-bluetooth@vger.kernel.org" <linux-bluetooth@vger.kernel.org>,
        "Stotland, Inga" <inga.stotland@intel.com>
Subject: Re: [PATCH BlueZ 2/3] mesh: Add DevKeySend call
Message-ID: <20190701200024.btxrfm2ndanzx7tm@kynes>
Mail-Followup-To: "Gix, Brian" <brian.gix@intel.com>,
        "linux-bluetooth@vger.kernel.org" <linux-bluetooth@vger.kernel.org>,
        "Stotland, Inga" <inga.stotland@intel.com>
References: <20190628125205.21411-1-michal.lowas-rzechonek@silvair.com>
 <20190628125205.21411-3-michal.lowas-rzechonek@silvair.com>
 <20190628132932.bhcvcx4tzlfkertu@mlowasrzechonek2133>
 <1561732393.7802.50.camel@intel.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <1561732393.7802.50.camel@intel.com>
User-Agent: NeoMutt/20180716
Sender: linux-bluetooth-owner@vger.kernel.org
Precedence: bulk

Hi Brian,

On 06/28, Gix, Brian wrote:
> Unlike App Keys, Device keys do not have a bound Net Key...  They can
> be sent on *any* network key.  So while sending a message on a
> specific App index implies the Net Key to use, the Dev Key send does
> not, and so needs it to be explicit.

After digging through the code, I've noticed that at the moment
bluetooth-meshd doesn't really support sending messages using
non-primary network key - this is because of internal API limitations
(see the TODO next to send_seg function in net.c).

Would it be OK for me to start implementing SendDevKey API in a way that
always uses the primary subnet, like it's currently done with
application keys? The same applies to calling DevKeyMessageReceived() on
the application side.

I am aware that a node is supposed to respond using the same subnet that
a request was sent through, but it's not that simple to implement in one
shot...

I'd very much like to add subnet support as well, but such a patch would
be much, much larger - I think I would need to modify internal APIs to
use mesh_subnet struct instead of mesh_net, and do it in many, many
places.

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