From: "Gix, Brian" <brian.gix@intel.com>
To: "michal.lowas-rzechonek@silvair.com"
<michal.lowas-rzechonek@silvair.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
Date: Mon, 1 Jul 2019 20:08:56 +0000 [thread overview]
Message-ID: <1562011734.458.14.camel@intel.com> (raw)
In-Reply-To: <20190701200024.btxrfm2ndanzx7tm@kynes>
Hi Michał,
On Mon, 2019-07-01 at 22:00 +0200, michal.lowas-rzechonek@silvair.com wrote:
> 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.
When this code was originally written, it only supported a single subnet.
I have no problem with functionality being added gradually, but we do eventually
need to be able send *everything* including all segments on the requested
subnet (not neccessarily the primary subnet). And there will be the problem that
nodes may exist that do not even have the primary subnet key.
>
> 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.
Forward progress is forward progress. I don't think any improvements will be
rejected unless they fundumentally restrict our future ability to make things
100% correct.
>
> regards
next prev parent reply other threads:[~2019-07-01 20:08 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-28 12:52 [PATCH BlueZ 0/3] Add support for remote dev keys Michał Lowas-Rzechonek
2019-06-28 12:52 ` [PATCH BlueZ 1/3] mesh: Rename APP_IDX_DEV to APP_IDX_DEV_LOCAL, add APP_IDX_DEV_REMOTE Michał Lowas-Rzechonek
2019-06-28 12:52 ` [PATCH BlueZ 2/3] mesh: Add DevKeySend call Michał Lowas-Rzechonek
2019-06-28 13:29 ` Michał Lowas-Rzechonek
2019-06-28 14:33 ` Gix, Brian
2019-06-28 17:18 ` michal.lowas-rzechonek
2019-07-01 20:00 ` michal.lowas-rzechonek
2019-07-01 20:08 ` Gix, Brian [this message]
2019-07-01 20:14 ` michal.lowas-rzechonek
2019-06-28 12:52 ` [PATCH BlueZ 3/3] mesh: Handle messages encrypted with a remote dev key Michał Lowas-Rzechonek
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1562011734.458.14.camel@intel.com \
--to=brian.gix@intel.com \
--cc=inga.stotland@intel.com \
--cc=linux-bluetooth@vger.kernel.org \
--cc=michal.lowas-rzechonek@silvair.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox