Hi Michał, On Mon, 2019-07-01 at 22:00 +0200, michal.lowas-rzechonek@xxxxxxxxxxx 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
