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:   Wed, 17 Jul 2019 10:48:53 +0200
From:   =?utf-8?Q?Micha=C5=82?= Lowas-Rzechonek 
        <michal.lowas-rzechonek@silvair.com>
To:     Brian Gix <brian.gix@intel.com>
Cc:     linux-bluetooth@vger.kernel.org, inga.stotland@intel.com
Subject: Re: [PATCH BlueZ 3/3] mesh: Propagate Net Index up Rx message chain
Message-ID: <20190717084853.copy2f3dc7oaglf4@mlowasrzechonek2133>
Mail-Followup-To: Brian Gix <brian.gix@intel.com>,
        linux-bluetooth@vger.kernel.org, inga.stotland@intel.com
References: <20190716225644.11449-1-brian.gix@intel.com>
 <20190716225644.11449-4-brian.gix@intel.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20190716225644.11449-4-brian.gix@intel.com>
User-Agent: NeoMutt/20180716
Sender: linux-bluetooth-owner@vger.kernel.org
Precedence: bulk

Hi Brian,

On 07/16, Brian Gix wrote:
> When a model receives a message, it is required by the spec
> to respond using the same credentials. When an App Key is used,
> this is trivial because App keys are bound to Net keys, so only
> the App Index is required.  Messages received on a Device key
> however, need the Net Index preserved from original message for
> re-use during the response.
> ---
>  mesh/cfgmod-server.c | 154 ++++++++++++++++++++++++++++-----------------------
>  mesh/model.c         | 129 +++++++++++++++++++++---------------------
>  mesh/model.h         |  10 ++--
>  mesh/net.c           |  92 +++++++++++++++++-------------
>  mesh/net.h           |   6 +-
>  mesh/node.c          |  10 ++--
>  6 files changed, 214 insertions(+), 187 deletions(-)
> 
(...)
> diff --git a/mesh/net.c b/mesh/net.c
> index a5693f154..ba52867c4 100644
> --- a/mesh/net.c
> +++ b/mesh/net.c
> @@ -119,7 +119,6 @@ struct mesh_net {
>  	unsigned int pkt_id;
>  	unsigned int bea_id;
>  	unsigned int beacon_id;
> -	unsigned int key_id_next;
>  	unsigned int sar_id_next;
>  
>  	bool friend_enable;
> @@ -203,7 +202,7 @@ struct mesh_sar {
>  	bool frnd_cred;
>  	uint8_t ttl;
>  	uint8_t last_seg;
> -	uint8_t key_id;
> +	uint8_t key_aid;
>  	uint8_t buf[4]; /* Large enough for ACK-Flags and MIC */
>  };
>  
> @@ -225,7 +224,7 @@ struct msg_rx {
>  	union {
>  		struct {
>  			uint16_t app_idx;
> -			uint8_t key_id;
> +			uint8_t key_aid;
>  		} m;
>  		struct {
>  			uint16_t seq0;
> @@ -668,7 +667,6 @@ struct mesh_net *mesh_net_new(struct mesh_node *node)
>  	net->node = node;
>  	net->pkt_id = 0;
>  	net->bea_id = 0;
> -	net->key_id_next = 0;
>  
>  	net->beacon_enable = true;
>  	net->proxy_enable = false;
> @@ -676,7 +674,7 @@ struct mesh_net *mesh_net_new(struct mesh_node *node)
>  
>  	net->seq_num = 0x000000;
>  	net->src_addr = 0x0000;
> -	net->default_ttl = 0x00;
> +	net->default_ttl = 0x7f;
(...)
> @@ -3408,18 +3421,17 @@ bool mesh_net_app_send(struct mesh_net *net, bool frnd_cred, uint16_t src,
>  	if (!src || !dst)
>  		return false;
>  
> -	if (ttl == 0xff)
> +	if (ttl == DEFAULT_TTL)
>  		ttl = net->default_ttl;
(...)

I would keep these in a separate patch, it's not really related to key
ids/indexes.

Otherwise, LGTM!

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